diff --git a/blog/2025-12-11.md b/blog/2025-12-11.md new file mode 100644 index 00000000000..e28146affd2 --- /dev/null +++ b/blog/2025-12-11.md @@ -0,0 +1,188 @@ +--- +title: Benchmarking Blockchain +authors: [matiasbenary] +slug: blockchain-finality-benchmark +tags: [benchmark, performance, finality] +--- + +While each blockchain has its own theoretical finality and transaction price, +we wanted to know: how long does my app *actually* need to wait for a transaction +to be final, and how much will it pay? + +To answer these questions, we sent transactions across 6 different chains to +compare both finality times and transaction fees. + + + +## Understanding Finality in Blockchain + +When you send a transaction on a blockchain, how long does it take to be truly irreversible? +This question is critical for developers building applications, especially those handling DeFi. + +When talking about finality, it is important to remember that generally there are two types of finality: + +- **Soft Finality (Optimistic)**: The transaction is included in a block and is *highly unlikely* to be reversed +- **Hard Finality**: The transaction is irreversibly committed to the blockchain with cryptographic guarantees + +For example, here are the **theoretical `optimistic` and `final` finality times** for 6 popular blockchains, +ordered from fastest to slowest (theoretically) in Hard Finality: + +| Blockchain | Optimistic Finality | Hard Finality | +|------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| +| Sui | 500ms | [500ms](https://docs.sui.io/concepts/sui-architecture/consensus#transaction-throughput) | +| Aptos | 130ms | [650ms](https://blockchain.news/flashnews/aptos-sets-industry-record-with-130ms-block-times-and-650ms-finality-implications-for-crypto-traders) | +| NEAR Protocol | 600ms | [1.2 seconds](https://pages.near.org/blog/blink-and-its-final-near-launches-600ms-blocks-and-1-2s-finality/) | +| Solana | 400-600ms | [13 seconds](https://solana.com/developers/guides/advanced/confirmation) | +| Arbitrum | [250ms](https://docs.arbitrum.io/launch-arbitrum-chain/faq-troubleshooting/troubleshooting-building-arbitrum-chain#what-is-the-max-theoretical-tps-for-an-arbitrum-chain) | [~15 minutes](https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#step-4-finality) | +| Ethereum Sepolia | [2.4 minutes (12 blocks)](https://ethereum.stackexchange.com/questions/319/what-number-of-confirmations-is-considered-secure-in-ethereum) | [~15 minutes](https://ethereum.org/roadmap/single-slot-finality/) | + +Despite what these theoretical numbers say, real-world performance can differ based on different factors, such as: +- Overhead from the RPC: free RPCs are expected to have higher delays +- Overhead from the network: chances are that your transaction will fall in-between blocks and need to wait for it to be processed + +Because of this, we decided to run an empirical benchmark to measure actual finality times and transaction fees across these blockchains. + +## Benchmarking the Chains + +To measure the **empirical** finality of the six blockchains mentioned above (NEAR, Aptos, Solana, Sui, Ethereum Sepolia, Arbitrum), we +built a simple benchmarking script which makes **30 transactions** per network, and computes how much - on average - a transaction takes +to settle when using both **optimistic** and **hard finality**. + +To be as fair as possible, we: + +- Used the `mainnet` network of all chains +- Used the simplest possible operation: a native token transfer +- Used free and public RPC endpoints + +### Defining Empirical Finalities + +It is important to remark that there is not a single definition on what optimistic finality means, and it can vary between blockchains. Here is how each blockchain in our benchmark defines optimistic finality: + +#### NEAR Protocol +On NEAR, optimistic finality is reached when the transactions reaches [`EXECUTED_OPTIMISTIC`](https://docs.near.org/api/rpc/transactions) finality, +which means the transaction is [included in a block and all non-refund receipts have finished their execution](https://docs.near.org/protocol/transaction-execution). + +For hard finality, one can simply wait for the transaction to reach [`FINAL`](https://docs.near.org/api/rpc/transactions). + +#### Aptos +For Aptos, optimistic finality is measured as the time when the transaction is submitted and the transaction hash is returned, without waiting for confirmation. +This represents the fastest possible response but with the least guarantees. + +For hard finality, we use [`waitForTransaction`](https://aptos.dev/build/sdks/ts-sdk/building-transactions) which waits until the transaction is committed to the blockchain and execution succeeds. + +#### Solana +Solana uses the [`confirmed` commitment level](https://docs.solanalabs.com/consensus/commitments) for optimistic finality, which means 66%+ of the validator stake +has voted on the block. For hard finality, the [`finalized` commitment level](https://solana.com/docs/advanced/confirmation) requires 31+ confirmed blocks +to be built on top of the transaction's block, making it economically irreversible. + +#### Sui +On Sui, their API exposes a function `WaitForLocalExecution` which waits for the local node to execute the transaction. + +For hard finality, the method [`WaitForEffectsCert`](https://docs.sui.io/concepts/sui-architecture/transaction-lifecycle) waits for an effects certificate, +which is a guarantee that the transaction will be included in a checkpoint and cannot be reverted. + +#### Ethereum +We did not find consensus on what defines optimistic finality in Ethereum, but multiple forums suggested to use 12 confirmations. + +For hard finality we can simply wait until the block is tagged as [`finalized`](https://ethereum.org/developers/docs/blocks/), which indicates the block has been accepted +as canonical by more than 2/3 of validators, typically occurring after two epochs (~12-13 minutes for Ethereum). + +#### Arbitrum + +Arbitrum is a layer 2 solution on Ethereum, meaning that it processes transactions off-chain and submits them to Ethereum for finality. For optimistic finality, +we simply measured the time it takes for a transaction to be included in an Arbitrum block (i.e. waited for `1 confirmation`). + +For hard finality, Arbitrum relies on Ethereum's finality guarantees, meaning that it will take as long as Ethereum to reach hard finality (~15 minutes), plus some +time for the API to reflect the finality status. + +## Results + +### Finality Times +Here is a table with the average finality times observed during our benchmark, ordered from fastest to slowest in Hard Finality: + +| Blockchain | Optimistic Finality | Hard Finality | Theoretical Hard Finality | +|---------------|---------------------|--------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| +| Aptos | 0.20s ± 0.01s | 0.62s ± 0.04s | [650ms](https://blockchain.news/flashnews/aptos-sets-industry-record-with-130ms-block-times-and-650ms-finality-implications-for-crypto-traders) | +| Sui | 1.49s ± 0.08s | 3.15s ± 0.03s | [500ms](https://docs.sui.io/concepts/sui-architecture/consensus#transaction-throughput) | +| NEAR Protocol | 2.35s ± 0.31s | 3.50s ± 0.24s | [1.2 seconds](https://pages.near.org/blog/blink-and-its-final-near-launches-600ms-blocks-and-1-2s-finality/) | +| Solana | 0.94s ± 0.25s | 12.97s ± 0.28s | [13 seconds](https://solana.com/developers/guides/advanced/confirmation) | +| Ethereum | 36.62s ± 15.05s | 1150.56s ± 5.92s | [~15 minutes](https://ethereum.org/roadmap/single-slot-finality/) | +| Arbitrum | 3.21s ± 0.31s | 1440.02s ± 161.90s | [~15 minutes](https://docs.arbitrum.io/how-arbitrum-works/inside-arbitrum-nitro#step-4-finality) | + +We can see that Aptos was the closest to its theoretical finality times, while for the rest of the chains there is an overhead +cause by the network and RPC layers. + +### Transaction Fees + +Here is a summary of the average transaction fees observed, ordered from cheapest to most expensive in USD: + +| Blockchain | Avg Fee (Native) | Avg Fee* (USD)| Fee Documentation | +|------------|------------------|---------------|--------------------------------------------------------------------| +| Arbitrum | 0.00000021 | $0.00000004 | [Docs](https://docs.arbitrum.io/how-arbitrum-works/gas-fees) | +| Aptos | 0.000012 | $0.00002 | [Docs](https://aptos.dev/network/blockchain/gas-txn-fee) | +| NEAR | 0.000045 | $0.00007 | [Docs](https://docs.near.org/protocol/gas#cost-for-common-actions) | +| Solana | 0.0000050 | $0.0006 | [Docs](https://solana.com/docs/core/fees) | +| Sui | 0.0015028 | $0.002 | [Docs](https://docs.sui.io/concepts/tokenomics/gas-in-sui) | +| Ethereum | 0.0000035 | $0.01 | [Docs](https://ethereum.org/en/developers/docs/gas/) | + +_* Based on token prices at the time of the benchmark_ + +It is important to note that transaction fees can vary based on network congestion, gas price, and of course the token price at the time of the transaction. +However, they will not vary based on the finality model used, since both optimistic and hard finality transactions pay the same fee structure. + +
+ + Token Prices at Benchmark Time + +| Blockchain | Token Price | +|------------|-------------| +| Ethereum | $3070 | +| Sui | $1.49 | +| Solana | $129.00 | +| Aptos | $1.59 | +| NEAR | $1.56 | +| Arbitrum | $0.20 | + +
+ +## Finality and Hardware Requirements + +Finally, we looked into the hardware requirements needed to run a full node or validator for each blockchain. Here is a summary of the minimum recommended hardware specs: + +| Blockchain | Hardware Requirements | +|------------------|----------------------------------------------------------------------------------------------------| +| Aptos | [32 cores, 64GB RAM, 3TB SSD](https://aptos.dev/network/nodes/validator-node/node-requirements) | +| Sui | [24 cores, 128GB RAM, 4TB NVMe](https://docs.sui.io/guides/operator/validator/validator-config) | +| Solana | [12 cores, 256GB RAM, 2TB SSD, 1Gbps](https://docs.solanalabs.com/operations/requirements) | +| NEAR Protocol | [8 cores, 8GB RAM, 1TB SSD](https://near-nodes.io/validator/hardware-validator) | +| Arbitrum | [4 cores, 16GB RAM, NVMe SSD](https://docs.arbitrum.io/run-arbitrum-node/run-full-node) | +| Ethereum Sepolia | [4 cores, 16GB RAM, 2TB SSD](https://geth.ethereum.org/docs/getting-started/hardware-requirements) | + +Interestingly, there is a correlation between **higher hardware requirements** and **better performance** (lower finality times). +This explains how Aptos and Sui achieved the fastest finality times, as they both require significantly more powerful hardware +for their validators - with the exception of Solana, which despite its high hardware requirements, has a slower hard finality due to its consensus design. + +## Summary + +| Blockchain | Hard Finality | Soft Finality | Cheapest Fees | Lowest Hardware | +|------------|---------------|---------------|---------------|-----------------| +| Aptos | 1st | 1st | 2nd | 6th | +| Sui | 2nd | 3rd | 5th | 5th | +| NEAR | 3rd | 4th | 3rd | 3rd | +| Solana | 4th | 2nd | 4th | 4th | +| Ethereum | 5th | 6th | 6th | 2nd | +| Arbitrum | 6th | 5th | 1st | 1st | + +## Resources + +The complete benchmark data and analysis tools are open source and available on GitHub: + +- **Benchmark Data**: [matiasbenary/benchmarks](https://github.com/matiasbenary/benchmarks) - Raw benchmark results and histograms + +:::info +While conducting this benchmark, we discovered that Aptos performed [similar testing](https://medium.com/aptoslabs/sub-second-latency-aptos-delivers-instant-transactions-4f6e8113c788) against Arbitrum, Avalanche, Base, Near, Optimism, Polygon, Solana, and Sui. +::: + +--- + +*Want to build on NEAR? Check out our [developer documentation](/smart-contracts/what-is) to get started.* diff --git a/blog/2026-01-06.md b/blog/2026-01-06.md index 9406f55c66a..126823996cd 100644 --- a/blog/2026-01-06.md +++ b/blog/2026-01-06.md @@ -1,5 +1,5 @@ --- -title: "NEAR Rust DevTools: Maintenance & Evolution Status Update 2025" +title: "Rust Tooling: Status and Evolution on 2025" authors: [frol] slug: near-rust-devtools-2025 tags: [articles] diff --git a/blog/authors.yml b/blog/authors.yml index 4f6fc7b7def..2efbec14ca3 100644 --- a/blog/authors.yml +++ b/blog/authors.yml @@ -59,3 +59,11 @@ pivortex: socials: x: ThePiVortex github: PiVortex + +matiasbenary: + name: Matias Benary + title: Developer + url: https://github.com/matiasbenary + image_url: https://github.com/matiasbenary.png + socials: + github: matiasbenary diff --git a/website/static/css/custom.scss b/website/static/css/custom.scss index 9b2faf408df..a645303e01b 100644 --- a/website/static/css/custom.scss +++ b/website/static/css/custom.scss @@ -223,23 +223,6 @@ h2 { font-size: var(--h2-font-size); } -/* Add an indicator after external links that'll open in a new window. */ -a[target="_blank"]::after { - content: "↗"; - display: inline-block; - height: 0.5em; - padding-inline: 0.2em; - vertical-align: text-top; -} - -a.menu__link[target="_blank"]::after { - display: inherit; -} - -a.cover-card[target="_blank"]::after { - display: none; -} - .auto-col { padding: 0 var(--ifm-spacing-horizontal);