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.
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 process 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.
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.
Alice and Bob are examples of placeholder names widely used in the field of cryptology. Alice and Bob are the original characters who want to transact, exchange a message or a cryptographic key. Many other interesting characters exist. Meet the rest of them:***
***Adapted from Wikipedia