| AEIP | 24 |
|---|---|
| Title | Efficient Validation and Aggregation of Signatures in Archethic Transactions |
| Author | Akshay Kumar KANDHI MANJUNATHA REDDY <akshay@archethic.net> |
| Status | Review |
| Type | Standards Track |
| Category | Core |
| Created | 2023-12-12 |
This AEIP proposes an enhancement to the Archethic blockchain's Transaction Chains, Transaction Validation Process, Transaction / Data Verification using Signature Aggregation Schemes. It addresses the storage and scalability issue related to transaction validation and transaction verification, particularly in the context of sharding where not all nodes store every transaction. The proposal introduces Aggregated cross-validation, Aggregated storage signatures. This will help to reduce the data footprint (instead of 200 signatures only 2 aggregated signatures will be needed) and also optimize network operations.
Currently below is the Pending and the Validated Transactions
Where:
@addr: An unused address that corresponds to the hash of the public key of the transaction that will succeed it in the chain.
Type: A type defining the functional role of the pending transaction.
Timestamp: The date and time of the transaction generation.
DATA: Data zone containing all the operations to be performed
Prev-PubKey: The public key associated with the previous transaction
PrevKey Sig: Signature from the private key associated with the mentioned public key to prove the possession of the private key.
OriginKey Sig: Signature from the private key associated with the device or software from which the pending transaction was generated.
Validation Stamp: The stamp generated by the elected coordinator node and containins
Cross Validation Stamp: To be considered as valid, the Validation Stamp must be joined by as many Cross Validation Stamps.
Storage Node Attestations: These attestations act as proof that the Storage Nodes have verified and stored the data.
The 2 problems with the current Transaction Chains are
Problem 1- Storage Space:
Every validated transaction in a transaction chain stores 200 signatures comprising of signatures of cross validation and storage nodes' attestation. Storing these 200 signatures for every transaction is not sustainable.
Problem 2- Fast Verficiation of Data on Archethic:
In the current Archethic network, a node querying other nodes that store a transaction chain has no way to verify the authenticity of this retrieved data, inorder to verify the retrieved data, the node has to collect the 200 signatures corresponding to the transaction and verify individually. This process of verifying 200 individual signatures is highly time consuming.
The new proposed solution consists of two aggregated entities: (As shown below) Aggregated Cross Validation and Aggregated Storage Signature
These aggregates will replace the extensive list of individual signatures, reducing the signature data by a factor of 200 and enabling faster verification. Hence they will contain
@addr: An unused address that corresponds to the hash of the public key of the transaction that will succeed it in the chain.
Type: A type defining the functional role of the pending transaction.
Timestamp: The date and time of the transaction generation.
DATA: Data zone containing all the operations to be performed
Prev-PubKey: The public key associated with the previous transaction
PrevKey Sig: Signature from the private key associated with the mentioned public key to prove the possession of the private key.
OriginKey Sig: Signature from the private key associated with the device or software from which the pending transaction was generated.
Validation Stamp: The stamp generated by the elected coordinator node and containins
Aggregated Cross Validation Stamp: To be considered as valid, the Validation Stamp must be joined by as many Cross Validation Stamps. These cross validation stamps will be aggregated into a single aggreagated cross validation stamp
Aggregated Storage Node Attestations: These attestations act as proof that the Storage Nodes have verified and stored the data. All these Storage Attestations will be individually aggregated into a single aggregated storage attestation.
All the steps remain the same, and only Step 8 is added to the Transaction Validation Process
Step 1: A transaction is sent to any node (welcome node).
Step 2: The welcome node selects validation nodes and forwards the transaction for pre-validation.
Step 3: Validation nodes retrieve necessary transactions for validation.
Step 4: Cross-validation nodes rebuild the context and communicate with the coordinating node.
Step 5: The coordinator node rebuilds the transaction context, completes the validation, and issues a validation stamp.
Step 6: Cross-validation nodes verify the validation stamp and issue their own stamps.
Step 7: Nodes begin the replication process and notify completion.
Step 8: Aggregated signatures are computed and replace individual transaction signatures.
Step 1: Alice sends the transaction to any node in the network (welcome node)
Step 2: The welcome node determines the validation nodes (coordinator and cross-validation) using Heuristic Algorithms, then forwards the transaction to the chosen nodes so that they can start the pre-validation work
Step 3: The elected nodes (coordinators and cross validation nodes) get all the transactions necessary for validation from the closest storage nodes: the complete chain on the storage nodes of the transaction, and all transactions related to unspent entries (UTXO)... on the respective storage pools. (Prev Storage Nodes)
Step 4: Once the context of the transaction has been rebuilt, the cross-validation nodes communicate to the coordinating node the list of storage nodes used to collect the data and their views on the availability of the validation and storage nodes.
Step 5: The Coordinator node, later has to rebuild the context of the transaction (chain, inputs, output), figure out the proof of work (PoW), compute the replication tree , define the operations on the ledgers and sign the validation stamp and transmit it to the cross validation nodes.
Step 6: The content of the Validation Stamp is verified by each cross-validation node which will further issue a "Cross-Validation Stamp" to the coordinator and other cross-validation nodes.
Step 7: Once all the Cross-Validation Stamps are received by each validation node, they can start the replication process of the validated transaction, as defined by the Coordinator node:
- Step 7a: the storage pool of the @Alice2 chain will recover the context of the transaction, if everything is compliant, store it in its local database and notify the validation and welcome nodes of the completeness of the replication.
- Step 7b: The storage pools assigned to @Bob and the nodes involved will check the transaction’s compliance and integrate it into their db.
- Step 7c: The storage pool related to the Beacon Chain will check the compliance of the transaction and integrate the timestamp and the addresses involved @Alice1, @Alice2, @Bob into the Beacon chain.
- Step 7’: The Storage Nodes will send their respective storage node stamp to all the other nodes involved in the transaction.
Step 8: The Storage Node along with Cross Validation and Coordinator node will calculate their respective aggregate signatures and replace the validated transaction signatures with the aggregated signatures. This is the final step of aggregating signatures and replacing the individual transaction signatures with these aggregated signatures is a method of compacting and finalizing the validation process, which is efficient and secure. All the nodes verify the aggregated signatures.
The current transaction validation method in Archethic is not scalable and requires significant network resources. This proposal aims to streamline the process, ensuring robust security and efficiency. The proposed solution not only saves storage space but also accelerates the data verification process on the Archethic network, which is crucial for maintaining high throughput and scalability as the network grows. The proposed changes are backwards compatible as they enhance the validation process without altering the underlying transaction structure.
In the context of the Archethic blockchain, BLS (Boneh-Lynn-Shacham) signature aggregation offers a transformative approach to handling transactions and signatures. Archethic, aiming to be a highly scalable and efficient blockchain, faces challenges typical of decentralized networks, such as the need to manage large volumes of transaction data efficiently. BLS signature aggregation directly addresses these challenges.
Why BLS? BLS has the special property of pairing. Why pairing? Pairing allows signatures to be aggregated. Why Aggregation? Although verification of BLS signature is resource intensive and expensive compared to ECDSA due to pairing operations, the benefits are: Time: verify all attestations in a single signature verification operation (verify N signatures with just two pairing and trivial elliptic curve point additions). Space: scale down N bytes of all signatures to 1/N bytes of aggregate signature (approximately and ideally). The benefits accrue when the number of signatures is more significant.
Here's how it works in the Archethic ecosystem:
-
Individual Signing: Nodes on the Archethic network sign their transactions with their private keys, creating individual BLS signatures. This step is analogous to standard digital signing processes but prepares for a more efficient aggregation.
-
Signature Aggregation: These individual BLS signatures from numerous transactions are aggregated into a single, compact signature. This aggregation is a powerful feature unique to BLS signatures, allowing the Archethic blockchain to condense what would normally be a large amount of signature data into a manageable size. This process is crucial for maintaining a lean and efficient blockchain.
-
Efficient Verification: The aggregated signature can be verified against a combined set of public keys corresponding to the private keys used in the signing process. This allows for the quick and secure verification of multiple transactions simultaneously, greatly enhancing the transaction throughput and reducing the computational load on the network.
By implementing BLS signature aggregation, the Archethic blockchain significantly enhances its scalability and efficiency. This approach reduces the storage and bandwidth requirements, a vital aspect for a blockchain designed to handle a high volume of transactions. Additionally, the inherent security of BLS signatures ensures the integrity and trustworthiness of transactions on the network. In summary, BLS signature aggregation aligns perfectly with Archethic's vision of a scalable, secure, and efficient blockchain network.
Results after BLS Signature Implementation:
The implementation to this is done in Rust!