• Transparency: All transactions are visible to anyone on the network, promoting trust and accountability. 
• Decentralization: No single entity controls the network, making it resistant to manipulation or censorship. 
• Accessibility: Anyone with an internet connection can join and participate in the network. 
• Immutability: Once recorded, transactions cannot be altered or deleted. 
• Innovation potential: Open access encourages wider development and adoption of new applications. 

• Privacy is crucial: Sensitive data can be protected within a controlled environment. 
• Specific access control is needed: Only authorized parties can view and modify transactions. 
• High performance required: Private blockchains can potentially achieve faster transaction speeds with fewer network participants. 

L3 Blockchain Performance Concepts 

https://forkast.news/what-is-layer-3-key-to-blockchain-future/

Layer 1s are characterized as the foundational blockchains like Bitcoin and Ethereum that have their own native cryptocurrency used to reward those who work to secure the network itself.

Layer 2s are protocols built on top of L1s designed to increase transaction speed and mitigate scaling difficulties of layer 1s while leveraging the security of the base chain. For example, Arbitrum is an L2 created to improve Ethereum’s speed of processing transactions as well as overall flexibility and scalability, and it has given birth to a broad range of DeFi protocols.

Layer 3s, on the other hand, offer even higher levels of customizability. At this layer, developers can carry out customized designs that L2s cannot easily achieve, especially for lower-cost execution and privacy-preserving functionalities.

• use cases are for custom blockchain solutions, not general purpose blockchain solutions
• L3s enable customized scaling and realize important functionalities — such as privacy — that L2s can’t effortlessly achieve on their own. L3s increase computation speeds and scalability of single applications by not having to share ZK-circuits with other applications on a single chain.

The current L2 serves as a general-purpose scaling, while L3 accomplishes customized scaling. 

For example, an L3, which adopts customized circuits depending on the demand of a specific decentralized application, can achieve better performance. Another example is Validium as L3. This design provides higher levels of throughput at a relatively low cost for decentralized apps by avoiding pushing compressed data to the L1 and utilizing validators to secure the digital asset. L3s can be employed as low-cost and high-performance scaling solutions that allow projects to have more choices for potential solutions, depending on their particular use cases.

L3 challenges now

1. One of the main challenges is the lack of standardized infrastructure for L3s. Since L3s are built on top of L2s, they require a standard infrastructure to operate efficiently. 
2. more development in ZK-rollup technology, which is the underlying technology for L3s. ZK-rollups have the potential to significantly improve the efficiency and scalability of L3s

The Graph - billable 3rd Party Blockchain Query and Indexing Service 

https://thegraph.com/docs/en/network/overview/

The Graph Network is a decentralized indexing protocol for organizing blockchain data. Applications use GraphQL to query open APIs called subgraphs, to retrieve data that is indexed on the network. With The Graph, developers can build serverless applications that run entirely on public infrastructure.

To ensure economic security of The Graph Network and the integrity of data being queried, participants stake and use Graph Tokens (GRT). GRT is a work utility token that is an ERC-20 used to allocate resources in the network.

Active Indexers, Curators and Delegators can provide services and earn income from the network, proportional to the amount of work they perform and their GRT stake.

https://www.linkedin.com/posts/natalie-antebi-97774654_blockchain-blockchain-citi-activity-7067099862013493249-crz8?utm_source=share&utm_medium=member_desktop

1) The Graph is a decentralized protocol for indexing and querying blockchain data.

2) Blockchain Explorer such as Etherscan, Blockchain.com , Blockchain Explorer are a type of Centralized Blockchain indexers that index low level data such as transaction, gas and etc.

3) When Dapps want to index higher level data (unique to their application), then can use 'The Graph' protocol and spin up a sub graph easily, making their data accessible while enjoying all the benefits of decentralization.

4) Using GraphQL makes querying the blockchain easy to use like google, you just need to create your own Scheme and define which smart contracts and events to listen to.

if you're passionate about Blockchain, dApps, and the future of web3, I encourage you to reach out.

How to use Blockchains for a specific use case?

Andy Martin

https://www.linkedin.com/posts/andy-martin-387188a_blockchainthoughtfortheday-tokeneconomythought4theday-activity-6988468305934098432-f06V?utm_source=share&utm_medium=member_desktop

I think there are clear use cases for private blockchains in addition to public ones - not just for ERP integrations. In my experience, engineering success assumes that we have a set of tools ( public, private, permissioned, permissionless blockchains, message services, other protocols, other methods of sharing information etc ) that we just assemble to fit a specific use case. Blockchain is only part of the picture, it's the use case which includes trust engineering that drives solution design, not the technology.

Engineers don't use just one type of data store for a solution. The same concept applies to blockchains. You use what is needed to fit the use case. Improvements are needed for consumption of blockchain service layers to reduce the work needed by most blockchain platforms today. Yes many different teams are working on this effort currently. I tend to lean toward the open source platforms like Hyperledger where that work is often more visible and consumable.

Potential Value Opportunities

Chainspect > Blockchain Performance Compared -  Normal Rate > Max Recorded Rate > Theoretical Rate 

Theoretical rate = useless << ignore chains that reference this

Normal rate = what you can expect if run apps and do normal tuning

Max Recorded Rate = best possible performance for the right use case well tuned

Block Time = time to create a block for the chain

Finality Time = time transactions are normally finalized on chain

Governance model for transactions = on chain, off chain, council

Great data comparing blockchains on TPS

https://chainspect.app/dashboard

Image Added

Real vs Actual TPS note - 2023

https://www.reddit.com/r/CryptoTechnology/comments/163drmq/understanding_real_tps_of_popular_blockchains/

To do this, we've used a straightforward approach. We connected to different blockchains, watched transactions closely, and then did some math based on the last 100 blocks. While blockchains have different speeds, we've kept things simple to focus on understanding TPS.

Let's check out the TPS claims of Solana, Arbitrum, Avalanche, Ethereum, and Bitcoin:

Solana claims "65,000 transactions per second," but the real TPS is 299.91. That's a huge 217 times difference.

Arbitrum talks about "40,000 transactions per second," but the actual TPS is only 8.07. That's a whopping 4956 times difference.

Avalanche says "4,500 transactions per second," but the real TPS is just 2.01. That's a significant 2500 times difference.

Ethereum's max TPS is 56, but the current TPS is 11.14. It's only 5 times different.

Bitcoin's theoretical TPS is 7, but in reality, it's around 4.18. That's just 1.67 times different.

To sum up, there's a big gap between what's claimed and what's actually happening with TPS numbers. While big numbers might sound good, the real measure of success for blockchain is how much it's actually being used.

Hyperledger Fabric v2.5 benchmark results

https://www.lfdecentralizedtrust.org/blog/2023/02/16/benchmarking-hyperledger-fabric-2-5-performance

Image Added

My actual performance experience on Fabric 2.4

The app had a transaction mix with most sizes between 800 and 2000 bytes

the actual write performance measured through Caliper load testing on a normal AWS test net setup ( 8 cores, 64 GB ) in 2022 ranged from: 

450 TPS to 680 TPS

Why does this matter? 

It wasn't an "optimized" app or test environment

Closer to what you might see IF you engineered an app well with MANAGED LOAD BALANCING on write requests, used moderate transaction sizes, focused on high speed write performance in a normal cloud environment.

Understanding TPS on a Besu Node

https://console.settlemint.com/documentation/docs/blockchain-guides/Hyperledger-Besu/performance/

Several crucial factors influence the transaction performance of a Besu node:

1. Network Latency: The time it takes for data to travel between nodes in the network and between the sender of the transaction and the node can significantly impact transaction speed.
2. Cloud Provider: Different cloud providers offer varying levels of performance, which can affect node operation.
3. Resource Pack: The selected resource pack determines the computational resources (CPU, RAM, storage) allocated to a node and the requests-per-second rate limit, both of which significantly impact performance and maximum throughput.

The process of executing a write transaction involves several time-consuming steps:

1. Transaction Preparation: This includes constructing the transaction object with the necessary parameters such as recipient address, value, and data.
2. Gas Estimation: Before sending a transaction, it's crucial to estimate the gas required. This involves a call to the node to simulate the transaction and determine the appropriate gas limit.
3. Nonce Management: Each account has a nonce that must be incremented sequentially for each transaction. Managing nonces, especially for high-frequency transactions, requires careful tracking and can introduce delays.
4. Transaction Signing: The transaction must be cryptographically signed. This can be done using Accessible Keys stored in Hashicorp Vault (in memory) or via AWS KMS. The signing process, while quick, adds to the overall transaction time.
5. Transaction Submission: Once prepared and signed, the transaction is submitted to the node's transaction pool.
6. Mining and Confirmation: Finally, the transaction must be picked up by a miner, included in a block, and confirmed by the network.

Transaction Consensus Models Vary in 2024 for EVM compatible chains

Key points to remember:

Ethereum's shift to Proof-of-Stake:
Ethereum is currently in the process of fully transitioning to a Proof-of-Stake model, which will significantly reduce the reliance on miners and instead use validators to secure the network

EVM compatibility and consensus mechanism:
While many chains are EVM compatible, meaning they can run Ethereum-based smart contracts, their consensus mechanisms can vary, with some still using Proof-of-Work (requiring miners) and others utilizing Proof-of-Stake (relying on validators).

Potential Challenges

Candidate Solutions

Comparing 5 Blochchain Platforms - Nov 2024

https://ankitakapoor23.medium.com/top-5-blockchain-development-platforms-compared-ethereum-hyperledger-polkadot-and-more-e87cfc1ded87

article is generally good on comparison features but inaccurate on performance data 

Solana does not do 65000 TPS

Step-by-step guide for Example

sample code block

Recommended Next Steps

Related articles