1. Purpose
1.1. Why was Elixxir created?
In 1985, the following appeared in a paper published by the Communications ACM:
“Large-scale automated transaction systems are imminent. As the initial choice for their architecture gathers economic and social momentum, it becomes increasingly difficult to reverse. Whichever approach prevails, it will likely have a profound and enduring impact on economic freedom, democracy, and our informational rights.”
Today, these words still ring true. Never before has the need for a scalable, confidential transactions platform been more apparent. Elixxir has been created to provide users globally with true digital sovereignty, the freedom to communicate and transact with the privacy they expect, and at the speed they enjoy.
Software development for the Elixxir project started in January 2018, with some earlier prototyping and design work in the previous year.
1.2. What is Elixxir?
Elixxir is as a decentralized messaging and payments platform capable of performing near the speed of a conventional, centralized platform at scale. To date, no decentralized technology has been able to process transactions quickly at the scale necessary for a global, mainstream user base, while preserving user anonymity and transaction confidentiality. The Elixxir platform enables hundreds of thousands of confidential, quantum-resistant transactions to be processed within seconds.
1.3. Who is behind the creation of Elixxir?
The team behind the creation of Elixxir is comprised of pioneers of practical, anonymous and verifiable cryptographic systems. Its members are among the first to propose and deploy digital currencies, mix networks, unpermissioned cryptography, anonymous user discovery, verifiable voting systems, and many other advances in cryptography. They have dedicated their collective decades of experience in this space to this breakthrough platform. The team is lead by Dr David Chaum.
2. Timeline
2.1. What stage is the Elixxir project in currently?
Elixxir recently emerged from stealth with the release of the technical brief and announcement of a functional AlphaNet, mid-September 2018. A visualization of a toy demo of an Elixxir block explorer is available on the Elixxir.io website. Details regarding the launch of the BetaNet and MainNet, release of the Elixxir whitepaper, token utility, tokenomics, and governance have not yet been announced and questions on these topics cannot yet be answered.
3. High-level Overview
3.1. What are the core design innovations of Elixxir
At a high level, Elixxir is a blockchain protocol that makes use of an advanced mix network protocol, cMix. In Elixxir, nodes teams, a feature of cMix, are arranged in a cascade, ready to sequentially process transactions in real time. The cMix protocol provides high throughput, network security, attack resilience and verifiability all while preserving privacy.
3.2. What is a node team?
The organization of nodes into teams is a defining feature of the cMix protocol and Elixxir. Nodes of the Elixxir network are deterministically selected pseudo-randomly and organized into a team. The existence of a selection of nodes into a given team is only temporary. Once a team of nodes has worked together to generate a block, the team they form is disbanded, with the nodes returning to a pool from which they can once again be selected to participate in a new team.
3.3 What do node teams do in Elixxir?
Nodes teams are responsible for generating the blocks of the Elixxir blockchain. The node teams process batches of messages and transactions of the Elixxir network together. The Elixxir network and operations of node teams utilize the Elixxir consensus protocol which employs a version of the cMix protocol adapted for the Elixxir platform. Node teams always process batches of messages and transactions. They never process a single message or transaction alone.
3.4. How is the randomness by which nodes are organized into teams generated?
A cryptographically secure pseudo-random function (that can’t be manipulated) determines which nodes get to go next. The Elixxir team will be releasing more information on this topic later.
3.5. What are the essential operations performed by a node team in the Elixxir consensus protocol?
There are two phases to the Elixxir consensus protocol. During phase I, precomputation, the team performs a computationally-intensive precomputation that produces a unique template defining how a batch of messages and transaction of a block will be processed. The template determines, but does not reveal, the order in which each transaction will be processed within the block, and how the transactions will be opened by nodes in the team. Independently, the nodes within the team agree and commit to the transactions without knowing the content of the transactions, and broadcast that commitment to all other team nodes.
The second, real-time phase begins once the batch arrives. Phase II of block generation takes less than 1/20th of the phase I precomputation time. As a team, the nodes open all transactions together in the predetermined order defined by the template, revealing their contents. When the team agrees that all transactions are valid, and commits have been made to processing the transactions properly, nodes again broadcast these commits to all other nodes. The team then executes all transactions. Each node independently generates and broadcasts a block that must be identical to the block produced by all other nodes in the team. In the Elixxir consensus protocol, nodes reach finality by evaluating short proofs that are propagated optimally through the network. As a result, the Elixxir consensus mechanism facilitates seconds-long finality times.(edited)
3.6. What is a cascade of node teams?
In Elixxir, teams of nodes are arranged to form a cascading sequence such that the points at which they begin their precomputations are staggered in time. At any point in time, a number of node teams exist at varying stages of precomputation completeness. When a batch of messages or transactions arrive to be processed, the next team of nodes in that cascade node team is poised with their precomputations complete and poised to begin phase II real-time processing. In this design, the vast majority of the computational work is completed before a batch of messages is received by a node team and many node teams are active at any given point at time performing phase I computation, ensuring that there is always a node team available to process the next batch of messages quickly in real time to create the next block.
3.7. How does Elixxir reduce the latency of block generation?
Elixxir reduces the block generation latency, through the use of cascades, through hash-based ownership, through staggered block propagation, and through commitment and proofs. Teams of nodes are queued up to process transactions quickly in real time, with precomputations already performed.
3.8. How are blocks propagated through the Elixxir network?
Once generated, block data is broadcast to each node within the next team in the cascade. From there, data is broadcast onwards to the rest of the nodes in the network. This sequence prioritizes communication to the next team responsible for block generation, ensuring efficient block propagation.
3.9. Does the Elixxir network require complete broadcasting or propagation across the network before a block is accepted as valid? Is block validity dependent on broadcasting and propagation?
Through the use of commits and proofs, the validity of blocks in Elixxir can be verified in the vast majority of scenarios. All scenarios where the block cannot be validated, the offender can be caught and ejected from the network. As a result, the system doesn’t require full propagation to accept the next block.
3.10. Do node teams compete with one another to be able to generate a block?
No, there is no competition between nodes to generate blocks in the Elixxir network. Teams are organized to generate a block which involves two phases of computational work. This computational work ensures the security of the network, allows for the validity of blocks to be verified, preserves the anonymity of senders and receivers, and the confidentiality of message content.
3.11. Can Elixxir and nodes teams corrupt message processing and block generation?
Elixxir node teams are unable to influence the consensus mechanism’s integrity. All aspects of block production are within the Elixxir protocol are independently predetermined in a strict, verifiable, and immutable manner. Additionally, all nodes in a team independently provide proofs that validate the block prior to final block confirmation.
3.12. Can transactions be verified to have been processed correctly?
To ensure proper system functionality, each and every node in a team independently generate cryptographic proofs as commits of batch integrity prior to a batch of messages or transactions being opened. In the event that commits do not match, any and all proofs produced by the nodes can be inspected to identify node failure or malfeasance.(edited)
3.14. What happens if just one node in a team is malfeasant?
The presence of one malfaesant node will taint the block produced. However, the anonymity of message senders and receivers will be preserved as well as the confidentiality of message contents. Furthermore, because all other nodes create commits that function as proofs, the incorrect processing by the malfaesant node can be proven. The block will be repossessed and the malfaesant node ejected from the network. With regard to payment transactions, in Elixxir, blocks represent updates to the ownership database, ie assignments of ownership of static tokens.
3.15. Does the presence of just one honest node in team preserve the integrity and privacy of a batch processed in a block?
Yes, without complete malfaisant cooperation by all nodes in a team, the anonymity of senders and receivers cannot be compromised.
3.16. What if all of the nodes selected in a node team are malfeasant?
The statistical probability of a fully dishonest node team being selected by the protocol is highly unlikely. If this eventuality did arise, such a fully malfeasant node team would be limited to only being able to change the order of transactions, de-anonymizing the transactions, or failing to provide a proof, i.e., faking a failure. The nodes are never able to compromise the confidentiality of message content. Through the use of commits that function as proofs, there is always a mechanism to restore user ownership after malfeasant assignment of token ownership. At worst, full team malfeasance is only able to slow the network down and compromise sender and receiver identity.(edited)
3.17. How do nodes qualify to be a part of the Elixxir network?
Nodes must be elected to participate in processing the messages and transactions on the Elixxir network. In order to be eligible for election, a node is required to stake tokens on the network and satisfy the verifiable, real-time inter-node performance tests. Elections in Elixxir utilize methodologies such as random sample voting and decoy balloting for honest and trustworthy elections by which users of the system can elect which nodes are verified to join teams, and which can be excluded. All elections in the Elixxir platform will use cryptographically secured, voter-verifiable, end-to-end election protocols. Once elected, a node is eligible to be placed into an Elixxir team. In the case that a node is malfaesant, this activity can be proven, and the node will be ejected from the network, losing both it’s eligibility to participate in the network, and it’s stake of tokens.
3.18. Who elects these nodes and what information is used to evaluate their candidacy?
Nodes are elected via an approval vote by the community. More details will be available in the white paper.
3.19. Does Elixxir use a PoW, PoS or DPoS consensus protocol?
No, the Elixxir consensus mechanism is not PoW, PoS or DPoS. Elixxir uses a novel consensus mechanism. Stake's only role in our consensus is to make sure nodes have skin in the game and have something to lose by acting maliciously. It does not influence the selection of nodes and stake is currently equal for all nodes, and ensures that nodes are incentivized properly.(edited)
3.20. What is alphanet/can we use it?
*The Elixxir AlphaNet is the Elixxir team’s internal test net and unfortunately is not yet available for use by the public. However, the Elixxir project will require node operators and users for our BetaNet. Please sign up to host a BetaNet at
https://elixxir.io/run-a-node.
3.21. What will be required to run a node?
The Elixxir team is aiming for nodes to be able to be run on desktop computers, but full specifications will solidify and get clearer over time. The reference implementation software is written in golang, with some python, bash, java (Android), swift (iOS) and javascript (ReactJS).(edited)
4.Batch Mixing and Mix nets
4.1. What is a mix network?
A sequence of nodes or servers that relay batches of messages/transactions in a way that detaches sender, receiver and content.
4.2. Why are mix networks used?
Mixnets anonymize batches of messages and transactions, preserving the confidentiality and integrity of each message or transaction. A mix network dissociates information about the sender, receiver and contents of a message.
4.3. What is the cMix protocol?
*cMix is a mix net protocol that enables batch processing of messages or transactions with high throughput. cMix exhibits significantly lower real-time cryptographic latency. A cMix protocol tailored for use in Elixxir forms a component of the overall Elixxir consensus protocol. *
4.4. How are messages processed cMix protocol?
Message processing involves 3 operations, Reception, Permutation and Delivery. The cMix protocol also features a Return Path, Commitments and a Group Opening.
4.5. What takes place during Reception?
During Reception, masking network encryption is added to each already end-to-end encrypted message, while user-to-network encryption is removed from it, disassociating the sender’s identity from the message. The end-to-end encryption remains.
4.6. What takes place during Permutation?
In Permutation, the order of messages within a batch is shuffled while adding more masking encryption, removing an observer’s ability to correlate the order in which messages were received with the senders’ identities.
4.7. What takes place during Delivery?
During Delivery, each node independently removes all masking network encryption, and sends the end-to-end encrypted message to its labeled destination. Payment transactions which are not end-to-end transactions are also finalized.(edited)
4.8. Can a receiver send a message back to sender when cMix has been used?
Yes! The cMix protocol has a Return Path feature that allows a receiver to send an immediate response through the mixnet; this permits receipts of transactions to be returned to users without the platform needing to know addressing information, thereby hiding the identity of the sender. To accomplish this goal, nodes generate additional keying material for the return path, and apply an inverse permutation so that responses arrive at the original senders.
4.9. What is a commit?
*Commits are a protocols that produce data, usually through hashing, that allow a third party to audit a computation performed by a node at a later date. *
4.10. When the cMix protocol is used, can nodes be verified to have processed messages correctly?
All messages exchanged between nodes, the permutations they perform, and all keying materials in the mixnet’s precomputation inherently function as commitments of how messages will be processed in the future, during the real-time phase of block generation. Nodes also produce a commit of the batch of encrypted messages before any decryption takes place. Commits function as an efficient mechanism for verifying that nodes perform their operations correctly.
4.11. What is a group opening?
During the delivery operation, before each node in a team decrypts the batch of messages they have received, they create a commit of the batch, confirm with one another that all commits are identical, and then proceed to decrypt the batch independently. This is termed a group opening.
4.12. Why are group openings used in Elixxir?
Group openings guarantees that all nodes in the teamwork on the same content before any sensitive information is received. This excludes nodes from modifying the contents by preventing any node from gaining access, and modifying content before the others gain access. This ensures that all honest nodes in the team are empowered to protect the integrity of the team and the properties they provide, namely confidentiality and anonymity.
5. Precomputations
5.1. What are precomputations?
Precomputations define phase I of a node team’s activity of generating a block. There are 5 steps involved in precomputation, during which the nodes work together to performing computations that generate a template defining how the batch of messages must be processed by each node independently during phase II once the when the batch of messages have been received.
5.2. What takes place during a precomputation?
During precomputation, the nodes work together, mirroring every action that will take place during the real-time processing of the batch in phase II.The product of each node’s precompution is a homomorphically encrypted template defining the three steps of the cMix protocol, namely, reception, permutation and delivery. Consequently, the template is completely defined before any message information arrives for block generation.
5.3. Why are precomputations used?
The use of precomputation ensures privacy and confidentiality, while dramatically increasing the speed at which batches of messages and transactions can be processed to generate a block once the batch arrives. It allows for most of the work and consensus to be achieved, the batch arrives, and produces commits that allow for verification that the batch was correctly processed afterwards.
6. Payments and Ownership
6.1. What is wallet-based ownership?
Simply, the user owns whatever is contained in the wallet. Token handling in most conventional blockchain systems today is wallet-based. The user controls access to a wallet by holding a private key. The wallet has an address on the blockchain and a private key is used to access the wallet. A public/private key pair is used to prove ownership of a wallet.
In wallet based ownership, users control the ownership of an address on the blockchain with a private key. Tokens on the blockchain can be moved from wallet to wallet. These movements are achieved through transactions. Ownership of the tokens in these systems is a product of owning, or knowing the private key that controls access to the address or wallet. Application of a hash function to the public key results in the wallet address. The long hexadecimal strings that users are familiar with using are simply hexadecimal representations of the private key, the public key and the wallet address.
6.2. Elixxir uses hash-based ownership. What is hash-based ownership?
Simply, the user owns whatever is assigned to the hash of their secret. In the Elixxir blockchain, tokens are static and do not move. Within Elixxir, assignment of ownership of a token changes, but the token does not move. A transaction in Elixxir involves changing the assignment of ownership from one hash, to another hash. The hashes, or images, are the product of applying a hash function to a preimage, or a secret.
6.3. What is a preimage?
A preimage, or a secret, can be a string of words, numbers or a file, as long as it is a valid input of the hash function. Since it is computationally infeasible to invert a hash function, one cannot use computational power to discover what the pre-image, or secret is. A preimage is the secret that is used to create an image. Whoever knows what the secret is, owns and controls the tokens assigned to an image on the Elixxir blockchain.
6.4. Why is hash-based ownership used?
Hash-based ownership is much faster to use and is quantum resistant. Since hash functions are considered infeasible to invert, users can use pre-images as proof of their ownership of specific images. By chaining this process of revealing these pre-images with the Elixxir protocol, users are able to perform payment transactions anonymously and securely. Furthermore, this process ensures that no one is able to forge a fake transaction in an attempt to steal someone’s tokens, because valid transactions require knowledge of these secrets to create them. In Elixxir, ownership of tokens is secured, not wallets.(edited)
6.5. How are payments processed in Elixxir?
In Elixxir, because tokens are static, tokens cannot be sent or received. Rather, ownership of a token’s value must be reassigned from one owner, to another. A simplified payment transaction in the system starts with an invoice. Bob sends Alice an invoice containing his image to which ownership of Alice’s payment should be assigned. After receiving Bob’s image Alice submits a payment transaction to the system that instructs the system to reassign ownership of the necessary quantity of tokens from Alices image, to Bobs. This transaction contains Alice’s preimage (secret), Bob’s image and the amount to be reassigned from Alice’s image to Bob’s image.
The system checks whether the preimage Alice sent is valid, and if it exists in the ledger, and then reassigns the specified amount from Alice’s image to Bob’s image. The amount previously owned by Alice, is now assigned to, and so owned by, Bob. After processing the transaction successfully, the system returns a proof receipt to Alice that she can share with Bob, which validates that the transaction executed correctly. This receipt provides proof that the transaction is properly recorded in the block by providing the Merkle path within the block of the token’s reassignment. This alone is enough proof that the transfer of ownership took place correctly, and that the tokens now belong to Bob. However, Alice or Bob can also check the blockchain and verify that the proper amount has been assigned to Bob’s image in the corresponding block.
6.6. What are the advantages of Elixxir’s payments protocol?
Elixxir’s unique architecture and payment processing mechanisms offer three advantages over traditional approaches: 1. User confidentiality is protected by the limited information that is available on chain. 2. Security is increased substantially by securing tokens instead of wallets. In the exceptionally rare event that a successful brute-force attack does occur, security of at most one token may be affected. 3. Transaction processing is faster because hash-based ownership can be completed in a fraction of the time required for a digital signature in traditional blockchain platforms.
7. Attacks
7.1. Is Elixxir susceptible to a 51% attack?
Any single honest node protects team consensus. An entirely dishonest team can only produce proofs for the transactions submitted by the set of users in that round. As such, nodes cannot create fake transactions to their own benefit, nor valid proofs for forged transactions. A completely dishonest team—an unlikely event—is limited to only being able to change the order of transactions, de-anonymizing the transactions, or failing to provide a proof, i.e., faking a failure.
7.2. Is Elixxir susceptible to a Sybil attack?
Within the Elixxir protocol, sybil attack resistance is created through the use of verifiable real-time inter-node performance testing, staking, and elections. Staking requires nodes to place a governance-determined number of tokens in an “escrow” that will be burned if they are expelled from the system for malfeasance. Elections in Elixxir utilize methodologies such as random sample voting and decoy balloting for honest and trustworthy elections by which users of the system can elect which nodes are verified to join teams, and which can be excluded. All elections in the Elixxir platform will use cryptographically secured, voter-verifiable, end-to-end election protocols. The Elixxir team has pioneered these protocols, being the first to propose such systems, the first to deploy them in a binding governmental election, and the first to use a blockchain for publishing election data in an election.
