...
- The future of consensus in Indy Node: proposal for moving from RBFT to Aardvark
- During the implementation of PBFT View Change, we tested PBFT selection of View Change and it seemed to be much better.
- Evaluating Aardvark versus fixing bugs with RBFT suggest that we should proceed to implement Aardvark.
- Evernym is considering doing this in 2019, but has not made a decision.
- Theoretical method growth in Ardvaark is n^2 instead of n^3 in RBFT.
- In theory, view change for RBFT is faster than in Aardvark / PBFT because the nodes have more information stored in the shadow masters.
- So there is a trade-off between faster view change versus faster throughput.
- Under attack, RBFT is expected to have more consistent throughput than regular PBFT and Aardvark.
- In practice, we would be using the same implementation of view change.
- How often does view change happen in practice?
- Under RBFT, view changes in the real world appear to be rare (days). It depends on the network conditions.
- We can select the Aardvark performance threshold to have regular view changes with the frequency we would prefer, under good network conditions.
- Update on Indy / Aries split
- foundation's POC on threading is currently on-hold.
- Adam has been looking at Rust parallelization / threading libraries. (See the Rocket framework for web servers for a good example.)
- Handlers vs Futures vs async/waits
- Sergey's POC of async / await (IS-1371) https://www.diffchecker.com/0WkrvEnt
- RFC for 37: Present Proof
- Describes a new object for presentation previews. Fills a gap in LibIndy; interim solution until we have full blown W3C VCs.
- Evernym thinks the next step is to move the Indy Wallet to Aries
- See discussion in 2019-09-25-A Aries Working Group Call (US morning)
- Kiva has plans for an aries-wallet
- Evernym's proposal is that indy-sdk-wallet → aries-ams (agent managed storage)
- Aries RFC 50 already documents the Indy Wallet
- See discussion in 2019-09-25-A Aries Working Group Call (US morning)
- As an Indy / Aries community, do we always have to wait for consensus on the details before people can contribute code?
Future Calls
- Define pull request review process for Indy Node.
- Should define the process, including how we handle exceptions (emergency fixes shouldn't be blocked, but would require notification)
- What is important in a good review?
- If a review must be skipped, should note it in the Git commit message.
- Non-secrets in the Indy Wallet
- Cam is working on pluggable crypto. They wallet shouldn't decide what encryption you should be using.
- Use cases where we would want to move keys between wallets
- Moving the link secret / credential data from one device to another (synchronized storage).
- Debug use cases
- Richard's hit other uses cases that were better solved with DID Doc, pre-signing, signing API.
- Work-around with the web-crypto API
...