arXiv subjects

Raghavendra Ramesh

Publications and source records attributed to Raghavendra Ramesh.

8 recordsLinked to original sources

arXiv2025

Efficient Parallel Execution of Blockchain Transactions Leveraging Conflict Specifications

Parallel execution of smart contract transactions in large multicore architectures is critical for higher efficiency and improved throughput. The main bottleneck for maximizing the throughput of a node through parallel execution is transaction conflict resolution: when two transactions interact with the same data, like an account balance, their order matters. Imagine one transaction sends tokens from account A to account B, and another tries to send tokens from account B to account C. If the second transaction happens before the first one, the token balance in account B might be wrong, causing the entire system to break. Conflicts like these must be managed carefully, or you end up with an inconsistent, unusable blockchain state. Traditional software transactional memory (STM) has been identified as a possible abstraction for the concurrent execution of transactions within a block, with Block-STM pioneering its application for efficient blockchain transaction processing on multicore validator nodes. This paper presents a parallel execution methodology that leverages conflict specification information of the transactions for block transactional memory (BTM) algorithms. Our experimental analysis, conducted over synthetic transactional workloads and real-world blocks, demonstrates that BTMs leveraging conflict specifications outperform their plain counterparts on both EVM and MoveVM. Our proposed BTM implementations achieve up to 1.75x speedup over sequential execution and outperform the state-of-the-art Parallel-EVM (PEVM) execution by up to 1.33x across synthetic workloads.

cs.DC↗

arXiv2024

Optimal Sharding for Scalable Blockchains with Deconstructed SMR

Sharding is proposed to enhance blockchain scalability. However, a size-security dilemma where every shard must be large enough to ensure its security constrains the efficacy of individual shards and the degree of sharding itself. Most existing sharding solutions therefore rely on either weakening the adversary or making stronger assumptions on network links. This paper presents Arete, an optimally scalable blockchain sharding protocol designed to resolve the dilemma based on an observation that if individual shards can tolerate a higher fraction of (Byzantine) faults, we can securely create smaller shards in a larger quantity. The key idea of Arete, therefore, is to improve the security resilience/threshold of shards by dividing the blockchain's State Machine Replication (SMR) process itself. Similar to modern blockchains, Arete first decouples SMR in three steps: transaction dissemination, ordering, and execution. However, unlike other blockchains, for Arete, a single ordering shard performs the ordering task while multiple processing shards perform the dissemination and execution of blocks. As processing shards do not run consensus, each of those can tolerate up to half compromised nodes. Moreover, the SMR process in the ordering shard is lightweight as it only operates on the block digests. Second, Arete considers safety and liveness against Byzantine failures separately to improve the safety threshold further while tolerating temporary liveness violations in a controlled manner. Apart from the creation of more optimal-size shards, such a deconstructed SMR scheme also empowers us to devise a novel certify-order-execute architecture to fully parallelize transaction handling, thereby improving the performance of sharding systems. We implement Arete and evaluate it on a AWS environment by running up to 500 nodes, showing that Arete outperforms the state-of-the-art sharding protocols.

cs.CR↗

arXiv2024

Moonshot: Optimizing Chain-Based Rotating Leader BFT via Optimistic Proposals

Existing chain-based rotating-leader BFT SMR protocols for the partially synchronous network model with constant commit latencies incur block periods of at least $2δ$ (where $δ$ is the message transmission latency). While a protocol with a block period of $δ$ exists under the synchronous model, its commit latency is linear in the size of the system. To close this gap, we present the first chain-based BFT SMR protocols with $δ$ delay between the proposals of consecutive honest leaders and commit latencies of $3δ$. We present three protocols for the partially synchronous model under different notions of optimistic responsiveness, two of which implement pipelining. All of our protocols achieve reorg resilience and two have short view lengths; properties that many existing chain-based BFT SMR protocols lack. We present an evaluation of our protocols in a wide-area network wherein they demonstrate significant increases in throughput and reductions in latency compared to the state-of-the-art, Jolteon. Our results also demonstrate that techniques commonly employed to reduce communication complexity$\unicode{x2014}$such as vote-pipelining and the use of designated vote-aggregators$\unicode{x2014}$actually reduce practical performance in many settings.

cs.DC↗

arXiv2024

Formally Verifying the Safety of Pipelined Moonshot Consensus Protocol

Decentralized Finance (DeFi) has emerged as a contemporary competitive as well as complementary to traditional centralized finance systems. As of 23rd January 2024, per Defillama approximately USD 55 billion is the total value locked on the DeFi applications on all blockchains put together. A Byzantine Fault Tolerant (BFT) State Machine Replication (SMR) protocol, popularly known as the consensus protocol, is the central component of a blockchain. If forks are possible in a consensus protocol, they can be misused to carry out double spending attacks and can be catastrophic given high volumes of finance that are transacted on blockchains. Formal verification of the safety of consensus protocols is the golden standard for guaranteeing that forks are not possible. However, it is considered complex and challenging to do. This is reflected by the fact that not many complex consensus protocols are formally verified except for Tendermint and QBFT. We focus on Supra's Pipelined Moonshot consensus protocol. Similar to Tendermint's formal verification, we too model Pipelined Moonshot using IVy and formally prove that for all network sizes, as long as the number of Byzantine validators is less than one thirds, the protocol does not allow forks, thus proving that Pipelined Moonshot is safe and double spending cannot be done using forks. The IVy model and proof of safety is available on Github.

cs.LO↗

arXiv2021

General Purpose Atomic Crosschain Transactions

The General Purpose Atomic Crosschain Transaction protocol allows composable programming across multiple Ethereum blockchains. It allows for inter-contract and inter-blockchain function calls that are both synchronous and atomic: if one part fails, the whole call execution tree of function calls is rolled back. The protocol operates on existing Ethereum blockchains without modification. It works for both public permissioned and consortium blockchains. Additionally, the protocol is expected to work across heterogeneous blockchains other than Ethereum. This paper describes the protocol, analyses it in terms of Gas usage and Finalised Block Periods for three scenarios: reading a value from one blockchain to another, writing a value from one blockchain to another, and a trade finance system involving five contracts on five blockchains with a complex call execution tree, and provides an initial security analysis that shows that the protocol has Safety and Liveness properties.

cs.CR↗

arXiv2021

Algorithm for Cross-shard Cross-EE Atomic User-level ETH Transfer in Ethereum

Sharding is a way to address scalability problem in blockchain technologies. Ethereum, a prominent blockchain technology, has included sharding in its roadmap to increase its throughput. The plan is also to include multiple execution environments. We address the problem of atomic cross shard value transfer in the presence of multiple execution environments. We leverage on the proposed Ethereum architecture, more specificially on Beacon chain and crosslinks, and propose a solution on top of the netted-balance approach that was proposed for EE-level atomic ðtransfers. We split a cross-shard transfer into two transactions: a debit and a credit. First, the debit transaction is processed at the source shard. The corresponding credit transaction is processed at the destination shard in a subsequent block. We use {\em netted} shard states as channels to communicate pending credits and pending reverts. We discuss various scenarios of debit failures and credit failures, and show our approach ensures atomicity even in the presence of a Byzantine Block proposer. The benefits of our approach are that we do not use any locks nor impose any constraints on the Block Proposer to select specific transactions. However we inherit the limitation of an expensive operation from the netted-balance approach of querying partial states from all other shards. We also show a bound on the size of such inter-shard state reads.

cs.DC↗

arXiv2020

Layer 2 Atomic Cross-Blockchain Function Calls

The Layer 2 Atomic Cross-Blockchain Function Calls protocol allows composable programming across Ethereum blockchains. It allows for inter-contract and inter-blockchain function calls that are both synchronous and atomic: if one part fails, the whole call graph of function calls is rolled back. Existing atomic cross-blockchain function call protocols are Blockchain Layer 1 protocols, which require changes to the blockchain platform software to operate. Blockchain Layer 2 technologies such as the one described in this paper require no such changes. They operate on top of the infrastructure provided by the blockchain platform software. This paper introduces the protocol and a more scalable variant, provides an initial safety and liveness analysis, and presents the expected overhead of using this technology when compared to using multiple non-atomic single blockchain transactions. The overhead is analysed for three scenarios involving multiple blockchains: the Hotel and Train problem, Supply Chain with Provenance, and an Oracle. The protocol is shown to provide 93.8 or 186 cross-blockchain function calls per second for the Hotel and Train scenario when there are many travel agencies, for the standard and scalable variant of the protocol respectively, given the Ethereum client, Hyperledger Besu's performance of 375 tps, assuming a block period of one second, and assuming all transactions take the same amount of time to execute as the benchmark transactions.

cs.CR↗

arXiv2020

Atomic Crosschain Transactions White Paper

Atomic Crosschain Transaction technology allows composable programming across private Ethereum blockchains. It allows for inter-contract and inter-blockchain function calls that are both synchronous and atomic: if one part fails, the whole call graph of function calls is rolled back. It is not based on existing techniques such as Hash Time Locked Contracts, relay chains, block header transfer, or trusted intermediaries. BLS Threshold Signatures are used to prove to validators on one blockchain that information came from another blockchain and that a majority of the validators of that blockchain agree on the information. Coordination Contracts are used to manage the state of a Crosschain Transaction and as a repository of Blockchain Public Keys. Dynamic code analysis and signed nested transactions are used together with live argument checking to ensure execution only occurs if the execution results in valid state changes. Contract Locking and Lockability enable atomic updates.

cs.CR↗