Open Value Sharing Protocol (Cycle Compensation)

[lastmjs]

MVP

• should we store the cycle sharing state across upgrades? For the MVP we have decided not to, devs will just have to pull down logs appropriately
• for the wallet payment should we check how many cycles were refunded? Because the logs will say that a certain amount of cycles were sent, but if they were refunded the logged amount will not be correct
• make sure to put the demergent labs .openvaluesharing.json file in the open_value_sharing crate
• do lots of manual testing especially to ensure that the dependency tree is correct
• Type the dependency tree?
  // TODO explain that the dev should only have one config object per platform
  // TODO as at least in Azle only the first ICP entry will be used
• // TODO perhaps this should be its own npm package inside of the open_value_sharing repo?
  // TODO should we also put the Rust implementation in that repo?
  // TODO should we then make these a crate and an npm package? think about crates and npm packages
• benchmarks, can we do it easily across all of our tests?
• introduce the custom field to the dfx.json, breaking change
• add auth to exposed methods, only the controller?
• The Rust dependencies? How do we do it for the Rust dependencies?
• Unit tests for Rust library
• Unit tests for Azle side?
• should we just property test for the unit tests though?
• Kybra implementation for use in icpp?
• can we somehow not require the dependencies to be searched twice when compiling?
• manually ensure the tree and everything is being calculated correctly...I saw some unexpected behavior with typescript or ts-node
• Why can't I get any manually-added Rust methods to show up in the candid file?
• it's hard to set kill switches and settings on individual canisters because they might share the same package.json...it's weird because the package.json kind of needs to be at the same level as dfx.json
• Still need to do
  • Clean up code
  • Write spec
  • Create crates/npm packages if desired
  • calculate cycle burn
  • implement timers
• Timer that goes off daily, weekly, or monthly
• Azle build process will search all dependencies in node_modules for a cycles address in package.json
• The timer will use notify and simply loop through all dependencies that want cycles
• A simple X% per year will be the target
• I think this will scale very well for now
• Heuristic is to give each level of the dependency tree 50% of the remaining amount of cycles that haven't been given out for that round
• Developer can turn cycle compensation off in the package.json or dfx.json
• Everything should be voluntary? Everything should be configurable?
• Should we turn this on by default right away? Or should we ease into it with a few versions?
• Once turned on we should conspicuously display it in the documentation, The Azle Book, the GitHub repo, and maybe on npm install in the terminal or on each deploy, or the first deploy? Or deploys to mainnet at least? If the first timer is at least one day into the future, seeing the message then would probably be a good enough warning
• How do we deal with sanctions/AML? We want zero friction but we might need to implement some sort of identity solution. Each library wanting to receive funds should be able to control who they receive them from. At first we can perhaps do a whitelist

Protocol-level

• Canisters need to be able to measure cycles consumed over periods of time
• Get rid of the need for the timer, the protocol will keep track of cycle burn
• Use batch transactions with the cycle ledger...but the protocol should just do the transfers automatically
• We might want to store this dependency cycle compensation information in the Wasm binary metadata section...but canisters would need to read this if they are going to do the payments. If the protocol does the payments then it can just read from the metadata section