Technology Assessment of Project Aber
Auther: Saudi Central Bank, Central Bank of the U.A.E., Supproted by IBM
Aber = "one who crosses boundaries’" in Arabic
Methodology
The assessment was performed in two stages.
First, a qualification criteria was used to come up with a set of candidate DLT technologies/protocols.
Ripple and Stellar, which are often positioned for cross-border remittance use cases, were ruled out because of the obvious need for permissioning and privacy for an interbank payment use case
Rusults of applying the qualification criteria
R3 Corda
Hyperledger Fabric (HLF)
JPMC Quorum
Second, an assessment criteria were used to evaluate the shortlisted technologies.
Rather than applying assessment criteria on the technologies directly, it was done in context of the cross-border interbank payment problem.
Assessment Criteria
the assessment was very specific to Aber requirements. several facets within a dimension, were considered and The facets were weighted according to their relative importance and levels were assigned scores between 10 and 100.
The following dimensions were considered:
Decentralization
Multiple levels corresponding to degree of decentralization (e.g. whether central banks need to authorize each and every transaction) and safety (e.g. whether decentralized was achieved at the cost of correctness or payment finality) were determined and assessed. Another facet considered was whether the solution needs a trusted setup phase.
Privacy
Different privacy levels were defined depending on what is protected from unauthorized access e.g. transaction data (amount), endpoints (sender, receiver), liquidity positions, time of payment etc. The protection mechanism and support for auditing despite privacy restrictions were also considered.
Scalability
several non-functional characteristics such as latency of payments and variation of latency and throughput with increasing number of nodes (banks), were considered.
Solution Complexity
the complexity and the effort required in building and supporting a wholesale CBDC solution based on the evaluated technology. This considered several factors such as overall complexity, level of reuse of existing CBDC designs, and complexity of managing the solution.
Security
There was a preference for PKI-based permissioning. Support for pluggable consensus was another factor considered, for instance, from the point of view of supporting byzantine fault tolerance (i.e. resilience in face of arbitrary and malicious behaviour). Builtin support for HSM standards was also considered a favourable capability.
Production Readiness
Like security, this dimension was largely dependent on the underlying technology. Various factors such as use of production ready components, operability, supportability and availability of production deployments based on the technology, were considered.
Long term viability
availability of skills, diversity of vendors involved in the project, extensibility, open standards and open governance were considered.
Assessment Result
https://gyazo.com/9a29180230aa8efc98f21c243527c2ad
Quorum(ZK1, ZK2)
ZK1 was similar to the Ubin Phase 2 solution using Quorum (MAS, Nov 2017), while ZK2 was based on and used techniques similar to Project Khokha (SARB, 2018).
Conclusion from assesment
HLF and Corda based solutions, by virtue of scoring higher in the ‘production readiness’ dimension, were considered more enterprise ready than Quorum based ones;
The approaches that use zero-knowledge proofs for validation do not scale very well with the number of network participants due to being computationally expensive;
Solutions that use built-in privacy features of a platform should be preferred to reduce solution complexity and reduce risk in trying to create one’s own crypto-schemes or similar.
The HLF-based solution was the only one that concurrently satisfied the privacy, decentralization and safety requirements of the pilot.
Based on this assessmen Hyperledger Fabric was selected as the technology for the implementation phase
tomoaki.iconメモ
RippleとStellarはpermissioningとprivacyの要件を満たさないからダメらしい。permissioningはできそうだけどな。あと、rippleってプライバシー保護技術ないんだっけ。
評価軸①Decentralization
単一障害点をなくすことに強い気持ちを感じる。Centeral Bankの全Txを承認がなくても大丈夫なら加点らしい。trusted setup phaseがあると減点らしいがなぜQuorumだけZKPを使う前提なのか(PETとしてPrivate Transactionが認められていないのかな)。そして今回のエンプラのユースケースではtrusted setup phaseがあっても問題ないと思う。
評価軸⑤Security
permissioningの可否(PKIに基づくものなど)が評価される。(BFTなど高い故障耐性の)コンセンサスもpluggableだと加点。HSMがビルトインで備わっていると加点。具体的にどの程度の故障耐性を持つかやネットワークモデルは考慮されていない。
評価軸⑦Long term viability
ベンダーの多様性、拡張可能性。オープンガバナンスなどが評価ポイント。明らかにセキュリティよりフワッとした評価軸なので並列にするのはよくないかな。
評価結果(図)
具体的に何を満たせば、何点加点されているのかが全くわからない。そしてQuorumはなぜZKPを使う前提なのか。フワッとしているからこそ具体的なツッコミがいれらない。
総じてQuorumに対して批判的。Cordaは要件に合わないので排除。結果、HLFという感じかな。