| Time | Item | Who | Notes |
|---|
| 5 min | Interaction between VM and Crypto | Michael Stay (Unlicensed) | - the VM is able to expose Crypto as primitives
- How are these called from Rholang? It's a matter of how we compile it to RBL
- As far as how the VM supports Crypto, implement them as Primitives, and link in a crypto library. Distribute the library as part of the VM
- this has issues with future proofing in that we would have to support that crypto primitive forever.
- An alternative is to use RBL's as a function interface, and expose it that way, that you load a library dynamically, grab the crypto function out of it and expose that (Use of the foreign function interface)
- It would differentiate Rholang from other languages. Other languages don't have too much of a plan, in most cases it requires a majority vote to upgrade the software. It would be up to the contract authors to build in a way to accept transactions that were after a certain date. The library of crypto functions would just be provided as a 'blessed' contract. These would be libraries that your contract would depend on.
- Eth messages are signed and validated before any computation occurs. Rholang doesn't work that way. Validation is part of the contract code you are writing.
- Eitan Chatav (Unlicensed) - it's a cool idea to make it a library through the FFI.
- Write a FFI and then provide the crypto as a library via a FFI in Rholang. We can provide a crypto api but then so can anyone else.
- FFI to Scala libraries? Should be stuff that implements Java.
- How do we guarantee that any node is implementing it correctly. This would be an oracle outside the consensus algorithm.
- Library should be purely functional, or else coming to consensus will be a challenge.
- Build it into the VM and at least we know they are running the right Crypto.
- Economic incentives are enough to encourage miners / node operators to do the right thing on providing functional code to the FFI.
- We need to come up with a way to import that, or declare a name that implements that.
- Best way to provide this is with a powerful object - like a system object with full capabilities and a channel.
- Assume that crypto will be made available on the channel, what does the API look like, what Tuples are needed, is it part of the crypto api's job to create the names and return these names to the client, etc..
- Contracts deployed to a validator set in the lexical namespace should expect to receive a powerful object or a resolver that you could go and look up one of these libraries.
- When a contract is deployed in Mercury, it gets a 'powerbox' of libraries and Crypto is one of those functions.
- Better to rip out things like 'print' from the language and use the ambient authority on the powerbox.
|
| Downsides |
| - Downsides - trusting contract owners to get crypto right. Not if it was a blessed library. Authors could write their own crypto, in the event they don't trust us. it would be slower.
|
| Venus | Michael Stay (Unlicensed) | - We will need for Contract authors to be willing to upgrade their contracts to Venus. This may involve doing some variable name substitution, re-compilation and re-deployment. Wouldn't be too different from upgrading any other language or SDK. Expect that there will be a new 'right' way to do things for Crypto come Venus. Path to upgrade may be easier if we already expect the contracts to receive a library parameter. Michael Stay (Unlicensed) isn't sure.
|
| Executive Decision | Michael Stay (Unlicensed) | - Contracts that are deployed to nodes will receive a channel on which they will have access to functions such as print, crypto, etc..
- Would like to see an API for a crypto library that handles signature validation, encryption private and public key and key management and a upgrade path for future ciphers. We may not do all of this for mercury, and we can stub out some of it for now, but we should know what it is going to look like.
|