...

Key Concepts

Blockchain Performance Concepts

...

1. buffer bc writes async
2. minimize write size
3. transaction aggregation
   block multiple transactions and hashes into single transactions using external index to find the block.transaction id to get the hash for proof
   1. create external index to individual transactions as async process ( not good for real-time confirmations )
4. sharding for parallel processing
5. horizontal scale
6. vertical scale with more powerful nodes
7. minimize nodes needed
   1. use logical members layer vs physical nodes to add orgs, accounts
8. upsize cluster
9. create logical acid transaction with confirmation prior to write completion - optimistic write w auto retry if failed
10. use off-chain data to answer most queries
11. use centralized network where the use case fits
12. use logical shards for the blockchain where it fitsleverage off-chain and world state databases for transaction updates and reads vs blockchain reads
13. push transaction data to encrypted, compressed blobs with NUK key sets, hash the blob & key sets, write hash and (optional) key sets to a block
14. use ZK rollups on off-chain transactions for data privacy, minimize data on-chain with rollup hashes, NUKs in hashed blocks with indexes of transaction keys to blocks for fast reads
15. consider transaction, block proof design that rolls up to the next level ( proof of proofs )
    1. anonymous state pinning article is another approach with advantages on information hiding
16. sharding for parallel processing
17. horizontal scale
18. minimize validator needs for transaction consensus
19. use ISSMR models to transmit on blockchain network vs simple leader to all propagation
20. vertical scale with more powerful nodes
21. minimize nodes needed
    1. use logical members layer vs physical nodes to add orgs, accounts
    2. id the right block validation model to fit the use case driving the minimum node network design
22. upsize cluster
23. create logical acid transaction with confirmation prior to write completion - optimistic write w auto retry if failed - separates commit vs finalization
24. use off-chain data to answer most queries
25. use centralized network where the use case fits
26. use logical shards for the blockchain where it fits
27. use caching where it helps

Fabric Blockchain Solution Engineering Concepts

For the enterprise DLT side we have flexibility on:

1. What is in a data blob, how it's encrypted and compressed for a use case
2. How we ID transactions uniquely on-chain and off-chain
3. How we build useful indexes to transactions for retrieval
4 How we hash data or hash a ZK proof of the data
5. What the validation policy is by contract
6. What time fence we want to keep transaction data before archiving on-chain and off-chain
7. Who, when and how we access archive data
8. How we map transactions and their hashes to blocks
9.How we handle rollups
10. How we use world state queries vs ledger queries
11. How we provide off-chain data access to organizations
12. How we share ledgers, contracts and ledger data
13. How we validate trusts in the transaction life cycle on access and on write
14. How we secure keys and signing processes
15. How we manage commit vs. finality on transactions
16. Which elements of a transaction life cycle are completed, events signaled and when the results are available to who
17. When, why and how we tokenize assets and integrate real assets
18. How and why we centralize or distribute data using on-chain and off-chain protocols
19. How and where to enforce security compliance rules for strong security and good performance
20. How we progressively optimize performance based on actual run-time experience
21. How we secure and recover wallets, accounts and assets
22. How we interoperate across chains

Lots of flexibility on the enterprise side in designing blockchain solutions

Fabric Internals - v1.4 - IBM au

...