Clemens Wan is a Solution Architect at Consensys. He writes lists of 30 seelemons.com.
If your choice of blockchain platform has less to do with the business factors (see 30 Blockchain Platform Business Factors), then perhaps you’re looking at some of the technical aspects for your use case. This list of 30 runs through blockchain-specific questions that should be top of mind when vetting a platform.
DevOps / Network / Deployment / Protocol
Blockchain layer deployment flexibility — Does the platform have a public instance? Permissioned? Private? Hybrid?
Optimal node count — How many nodes are needed to support the network? One for each member? Can I interact with the network without running a node?
Containerization — Can the platform be dockerized and deployed via Kubernetes?
Network identity management layer — How are permissions for nodes and individuals managed? Are there limitations to super users? Is there a source network map of all parties in the network (e.g. DNS-like service — ENS in Ethereum)?
Consensus mechanism — Is the system based on Proof of Work? Proof of Stake? Proof of Authority? Proof of Elapsed Time? This is probably decided by the governance setup and entities based on what is most effective for your use case.
Messaging between organizations — Are there separate layers for private messaging? Is this AMQP-based? RabbitMQ? XMPP? Secure Scuttlebutt?
Transaction processing methodology — What order of activities occurs in terms of transaction processing? When does the protocol order, validate, and execute the transactions? In Ethereum, TXs are sent to validating nodes that order/validate prior to executing and distributing the “correct” block. In Corda, TXs are validated individually by the need to know nodes through the Flow Framework until it gets signed and redistributed by the notary.
Cryptography — What libraries are used and supported by the hashes and signatures? (e.g. secp256k1 for Ethereum)
Pluggability of cryptography — Can specific nodes choose to use a different crypto library based on their regional security rules? (e.g. NIST compliance)
File-sharing techniques — Every digital asset must be somehow legally anchored through the organization holding it custody or the legal document/prose referenced in the code. How are files shared between organizations with the platform? Are they saved on the same platform? Are they backed up similarly?
Legal anchoring — Is there built in legal prose or legal document implementation (e.g. OpenLaw) within the protocol?
Tamper-evident vs. tamper-resistant — Can someone change your local node state and its history? If somehow a transaction or state were removed, would it cause everything to be out of sync? Is the referenced historical data able to be modified or deleted and agreed upon by all parties?
Transaction recovery — How does a node recover the transactions? If your transactions are not fully distributed to all parties then what are the mechanisms of downloading the latest agreed upon version?
DAO Capability — Are there examples of dapps that abstract the governance responsibility? This may be useful for reusing the network to maintain voting and governance.
Developer Experience / Top of Stack Applications
Application responsibility — When building your top of stack application (dapp), what do you need to worry about? Do you have to host your own node? Are you also responsible for deploying the dapp’s corresponding web servers and interfaces? How will your users pay for your application?
Dapp layer deployment — Based on permissions, how are smart contracts deployed in the network? By an individual (e.g. whitelisted address)? By a node (e.g. LEI’s identity)? By a registered entity (e.g. business network added to the network)? By the infrastructure provider (e.g. Kaleido Marketplace)? Do you need node-level permissions to deploy?
Smart contract languages — What language is the smart contract written in? Has it been tested? Does it have a good community?
Smart contract libraries and standards — Are there agreed upon secure libraries/functions (e.g. OpenZeppelin) that are maintained and audited? Are there widely agreed upon implementations of functions rolled up to standards (e.g. ERC-20, ERC-721, etc)?
Smart contract upgradability — How are applications updated? Are there well defined upgrade patterns for the smart contract code?
Access to reference and market data — Within the network, what available oracles can be called to receive the necessary information to execute a triggered action?
Recommended identity management of individuals — Do the public/private key pairs and addresses naturally insist that individuals maintain their own keys? Or is this realistically assuming that intermediaries will host them on your behalf and still have account management distributed across client preference?
Interop within apps or networks — Can a dapp call another dapp? Can a network/side-chain reference information from the tethered network?
User Control / Performance / Privacy
Transaction processing performance — How quickly can you queue up transactions, process them (in batches/blocks), and make sure the queue is cleared with notification of “saved”?
Scalability of transaction processing — Is the system designed with modularaly scalable (horizontally or vertically) to support higher processing rates?
Concurrent changes — Are there roadblocks to updating the same contract or balance multiple times before the asset is fully changed?
Transaction distribution performance — When does your transaction get updated to all parties? Is it when the block is processed? After 6 block depths? After the flow has completed and signed by all parties?
Multi-threading — Can your transaction processing and consensus be multi-threaded or sharded across multiple network participants and still agree on the same golden source? Do you split different types of executions?
Privacy mechanisms for field obfuscation — Can you share specific fields of the data storage mechanism with only specific users? Can you run business logic that compares field values without revealing the information (e.g. Aztec and ZKsnarks)?
Privacy mechanisms for receivers (confidentiality) — Can you rotate public keys automatically such that the end user you’re sending the information to is not resolvable to a known identity?
Privacy mechanisms for senders (transaction traffic patterns) — Can you not share the transaction to all parties in cases where you want only your identified parties to see the transaction?
Consult our blockchain experts
Our global Solutions team offers blockchain training, strategic advisory, implementation services, and partnership opportunities.