Your Smartphone Can Soon Verify A Solana Transaction
Solana proposes its first light client, SIMD-0052, a crucial development in blockchain tech. It allows users to verify that transactions are included in specific blocks, locally on their low-power devices, such as smartphones, enhancing accessibility.
- Author: Illustrious
- Published: June 13, 2023 at 10:40
The world of blockchain and decentralized finance is set to take a significant leap forward with the proposal of Solana's first light client, SIMD-0052 - Consensus and Transaction Proof Verification. This article will explore what this proposed client is, why it's a necessary development in the Solana ecosystem, and how it will function.
Understanding the Light Client
In blockchain parlance, a light client refers to a network participant that does not run a full node but instead interacts with the network through a trust-minimized interface that eliminates the need for large hardware resources. This way, users can access the network and verify transactions on devices with relatively low computational power, such as smartphones.
The initial version of Solana's light client is designed to function as a Simple Payment Verification (SPV) client that verifies two primary aspects:
- That a specific transaction of interest has been included in a block.
- That the block in question has been approved by a trusted set of validators.
However, up until now, Solana has not had a way to verify that a transaction has indeed been included in a block. This is where SIMD-0052 comes in.
Why SIMD-0052 is Necessary
SIMD-0052 is a groundbreaking proposal because it offers a way for users to verify locally that a transaction has been included in a specific block. This means that a user can now verify transactions on their devices without any overhead.
This proposal introduces two main changes for transaction verification:
- The addition of a new RPC method which provides a proof that a transaction has been included in a slot.
- The modification of the blockhash to be computed as a Merkle tree of entries and to include transaction statuses.
The new RPC method enables users to verify proofs locally on the client side without additional overhead, while the modified blockhash calculation allows for more precise transaction verification.
A Deep Dive into Solana Internals
In Solana, each slot is identified by a bankhash that comprises a parent hash, accounts delta hash, signature count, and recent blockhash. The network's supermajority then signs on this bankhash during consensus. However, two problems exist:
- Verifying transaction inclusion would require all the entries to be hashed again, which is computationally intensive.
- We cannot verify whether a transaction is successful, even if it is included, as statuses are not part of the blockhash.
To address these issues, SIMD-0052 proposes that the blockhash be calculated in a new way: by constructing a Merkle tree of entries instead of a simple hash and by including the transaction status in the Merkle tree of the batch of transactions that are part of the entry.
Moreover, Max Schneider has suggested including transaction logs in the Merkle tree, which is a recommendation that will soon be incorporated into the SIMD.
The Impact of the New RPC Method
In addition to modifying the blockhash calculation, SIMD-0052 proposes a new RPC method to obtain proofs of transaction inclusion. These proofs can be used to compute the root, i.e., the bankhash, locally. This allows users to verify transactions without the need for high-powered computing resources.
In summary, SIMD-0052 - Consensus and Transaction Proof Verification introduces critical innovations that enable the creation of Solana's first light client. These enhancements are a significant step forward in making blockchain technology more accessible and user-friendly, enabling users to verify transactions on low-power devices with ease.
If you're interested in the more technical aspects of these changes and how they're implemented in the light client, you can refer to the detailed design section and diagrams in the SIMD here.