Xand Blockchain for Fin Services nets
- jimm1
Owned by jimm1
Key Points
What service levels does Xand deliver? ( see VCE )
Are Xand services layered using standard interfaces for flexible implementation?
Does Xand leverage or replace capabilities of underlying platforms?
What identity, IAM models does Xand support for services?
What service dependencies does Xand have?
What client interface capabilities does Xand offer now? possible extensions?
What are the Xand details on dynamic metadata definitions for: objects, services, data models, relations, events, workflows, analytics, processes, validations, transactions, governance?
What platforms, services does Xand consume?
What platforms, services does Xand integrate with?
What platforms, services does Xand connect to and extend?
What regulatory approvals, licenses does Xand operate with?
What is the Xand community sustainability?
What is the Xand VCE maturity level?
How does Xand score on FACTUR3DT.IO compared to other DLT platforms?
References
| Reference_description_with_linked_URLs__________________________ | Notes__________________________________________________________________ |
|---|---|
| Xamd blockchain services folder | |
| xand-overview-jmason gdoc | |
| https://transparent.us/docs/xand-technical-white-paper.pdf | |
| https://transparent.us/docs/xand-confidentiality-white-paper.pdf | |
| https://ieeexplore.ieee.org/document/8939262 | |
| FDIC letter from Xand for CBDC networks 2021 | |
Session Overview
Key Concepts
Xand Capabilities Chart
| Xand_________________________ | Enterprise Ethereum | Fabric | Corda | |
| Node Permissioning | Smart contract based rules, with file-based per-node rules as local overrides. | Configurable on node, channel and consortium levels. | Trusted network map service complemented by file-based configurations on each node. Corda networks are partitioned into compatibility zones that are governed by separate Certificate Authorities. | |
| Identity | Public keys – distributed, and interoperable between Ethereum based chains. Coupled to PKI via proofs. | Based on PKI with native organizational identity. Organizational identity rather than individual identities used throughout in consensus, and permissioning. | Based on PKI with both individual and organizational identity. | |
| Cryptography | secp256k1 | Pluggable (ECDSA with secp256r1 and secp384r1 built-in). | ed25519 secp256r1 secp256k1 RSA (3072bit) PKCS#1 SPHINCS-256 (experimental) | |
| Transaction Consensus | Order -> Execute/Validate | Execute -> Order -> Validate | Execute/Validate -> Order/Notarize | |
| Application Responsibility | Sending signed transactions to one node in the network. | Coordinating directly with all required participants to obtain endorsement, checking for consistent execution results, signature, and submission. | CorDapps use the flow framework to coordinate with transaction counter-parties to negotiate proposed updates, obtain signatures, and to finalize with the notary service. | |
| Applied Consensus Algorithms | Proof-of-Authority (BFT). Raft (CFT with trusted leader). Istanbul BFT (BFT with deterministic leader rotation). Tendermint | Kafka/Zab (CFT with trusted leader). Raft (CFT with trusted leader). | Raft (CFT with trusted leader) BFT | |
| Smart Contract Engine | EVM, in-process sandbox | Docker isolation by default, pluggable in v2.0 | Deterministic JVM | |
| Smart Contract Languages | DSL (Solidity, Serpent), guaranteed deterministic. | Full languages (Go, Node.js, Java), non-determinism is tolerated. | Java, Kotlin, deterministic by using recommended libraries | |
| Smart Contract Lifecycle | Immutable. Easy to deploy. Stored on-chain. | Requires elaborate process to deploy/change. Stored off-chain. | Requires node-level administrative operations to deploy/update. Stored off-chain. Ongoing work to split consensus-critical code vs. non-consensus-critical code for different storage strategy (on-chain vs. off-chain respectively) | |
| Smart Contract Upgrade | Programming patterns to extend/migrate code & data. | Replacing off-chain code via administrative procedure and upgrade transactions. | Contracts with hash-based constraints are explicitly upgraded via node-level administrative procedures and coordinated flow to authorize and upgrade. Contracts with signature constraints automatically allow new versions to execute, as long as signed according to the constraints and the hash matches. | |
| Tokenization of Assets | Native feature Many token standards: ERC20/ERC721/ERC777 etc. | Possible with custom solution. | Possible with custom solution. Corda Token SDK makes it easier to build. | |
| Multi-chains | Each chain is unique, and requires separate node runtimes (min or 3 or 4 depending on consensus). | Native feature (channels) with shared peer runtime, and shared orderer. Built-in governance for creating side-chains with isolated state. | No concept of a chain (shared ledger). Transactions always explicitly target specific nodes. States are scoped to the designated notary which can be retargeted to a different notary. | |
| Private Transactions | Public hash represents input. | Public hash represents input and private end state. | Inherently all transactions are private. The entire transaction is visible to a validating notary. | |
| Community of Contributors (as of writing) | Go-Ethereum: 429 Quorum: 383 Besu: 60 Autonity: 360 | Fabric: 185 | Corda: 146 | |
| Community Pulse (Month of Nov. 2019) | Go-Ethereum: 15 authors, 98 PRs Quorum: 9 authors, 13 PRs Besu: 23 authors, 66 PRs Autonity: 6 authors, 6 PRs | Fabric: 31 authors, 220 PRs | Corda: 33 authors, 91 PRs |
Ethereum Enterprise Blockchain implementations
| EE Client | Modified From | Developer | Open Source License |
| Quorum | go-ethereum | JPMorgan Chase | LGPL |
| Besu | New implementation in Java | PegaSys | Apache 2.0 |
| Autonity | go-ethereum | Clearmatics | LGPL |
| Strato | Haskell Ethereum | BlockApps | Closed-source |
Potential Value Opportunities
Potential Challenges
Candidate Solutions
Step-by-step guide for Example
sample code block