Summary
| Excerpt |
|---|
|
Recording of Call: dummyfile.txt
|
Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit the Hyperledger Code of Conduct. |
|---|
Welcome and Introductions
...
- Update on CI/CD Update and Ubuntu Upgrade
- Indy Shared GHA Repo
- Indy-Plenum:
- Indy-Node:
- indy-test-automation:
- indy-node-container:
- Call time changed – 17:00 CET / 8:00 Pacific on Thursdays.
- Indy-SDK build progress
- Related work - Sovrin token-plugin repo being reworked to match indy-node/plenum.
- Mostly done the code.
- Working on the pipeline
- Linting issues documented and being cleaned
- The root cause of the "Mixed Node" issue has been found – and it's not a mixed node issue.
- Christian Bormann has been investigating and looks like he's figured it.
- Issue: The merging of the RevRegEntry arrays into the RevReg was implemented in the past without a specified ordering. Such a merge is implemented differently between Python 3.5 and later, such that the merged array is in a different order in the 20.04 code, and so causes the root hash to be different between implementations. The result of the root hash differences is a 20.04 node as it stands today cannot join consensus.
- Options to address the issue that were discussed:
- Go back in time and add a ".sort" to the merge command.
- No one admitted to having a time machine, so the idea was dismissed.
- Rewrite history to update the existing transactions to be sorted, including updating the audit log.
- Deemed highly risky and inappropriate for a blockchain-based solution.
- Call out to a Python 3.5 program to do the merge.
- Deemed to be a tech debt that must last forever.
- Write a version of the Python 3.5. merge routine (C code) in Python to get the same order as previously. Use this from now on.
- Deemed a possibility, but with the risk that the Python code would have to work on existing and future transactions.
- A consideration here is if we can find a pattern that results in a difference in the merge outcomes, such that we think it is safe to use this approach from now on.
- Write a version of the Python 3.5. merge routine (C code) in Python to get the same order as previously. Add a config transaction to the ledger and use the ".sort" code after the config, use the "old" code before the config. Make sure that the Python code handles all the transactions before the config.
- This seems the best option, although the logistics at upgrade time are painful.
- Go back in time and add a ".sort" to the merge command.
- Actions:
- Daniel Bluhmto take a look at the C code here to see about doing a Python version.
- We should also do some searching on the web to see if others have done that.
Future Calls
- GDPR and the right to be forgotten – mitigations and approaches.
- Dealing with Indy Node DoS attacks.
...