demergent-labs / ic-strategy-planning Goto Github PK

We don't want to think about the 4GB limit, or having to transfer memory in and out. You don't think about multi-canisters or which type of storage. You just store stuff.

These are my thoughts on the ideal token standard. I don't plan on implementing my own, I just want to use this information to inform discussions around coming to consensus on a standard as a community:

• accounts and balances
• account identifiers (principals or addresses??)
• transfer
• transfer_safe
• transfer delegations? (the ability to delegate the power to transfer to other accounts)
• history
  • blocks?
• verifiability
  • validity proofs?
  • blocks?
  • verifying the ledger itself and the implementation itself
• privacy
  • should blocks be publicly exposed?
  • should blocks/transactions only be exposed to participants in a transaction?
• DOS prevention
• Notifications
• Receipts (a transfer would atomically return a verifiable receipt of the transfer that could be passed along to interested parties)
• Atomicity (this might negate the need for receipts, as transfers could occur atomically with other update calls)
• Extensibility (this might be covered just fine by a canister's ability to extend itself)
• Fungibility? Should we have two standards are one standard?
• Automatic cycles top-up (cycles bonding curve?)
• Transaction fees
• Subnet size (we may want to agree upon the replication factors of subnets depending on the security requirements of a token)
• Scalability (transaction throughput and storage)
• Formal verification
• Property-based tests
• Multiple independent audits
• Test suite that other implementations can use
• Minting, burning, or fixed supply
• Who should be allowed to pay for fees? I think fees should always be payable in the token, but perhaps the receiver should be allowed to pay the fee

Current Proposed Token Standards

• IS20
• DIP20
• Extendable Token Standard
• Deland Labs fungible-token-standard

We want to be able to send ICP/ledger tokens as parameters to update calls

There might be use-cases where you need a file system like S3 or Object Storage.

This is more of a maybe.

Subnet finalization rates drop often, and sometimes subnets go read-only for long periods of time.

Heartbeat right now is way too expensive basically because it runs ~every second. We should be able to customize this, very similar to other cron solutions. We also need to be able to register multiple heartbeats within a single canister.

Prior Art

• Most in-depth conversation about heartbeat limitations: https://forum.dfinity.org/t/heartbeat-getting-called-before-init-is-finished/11945/10?u=lastmjs

Next Steps

• Open a dedicated Governance Proposal post

These are the most important protocol features that Demergent Labs will push for in 2023.

• Wasm binary size limit (coming ~Q2 2023)
  • Will drastically reduce Azle/Kybra compile times
  • Will remove the need for ic-cdk-optimizer (major source of compile times)
  • Will allow Python stdlib and PyPI packages in Kybra
  • Will allow larger npm packages in Azle (like Motoko JS runtime)
  • Will remove the need for gzip, which adds complexity to build process and dfx.json for the developer
  • Will remove the need to install and use ic-wasm just to put custom metadata sections back
  • Will allow us to implement (hopefully) async/await in Kybra
• Stable data structures (especially removing max key and value sizes and recovering memory)
  • Will make development with stable structures much simpler (major source of complexity for devs)
  • Will remove the need to add many directives and extra complexity in Sudograph
  • Will allow developers to use the maximum stable memory size
• Increases in stable memory size (100 GiB+)
  • Will make single-canister development, stable structures, and Sudograph more attractive to devs
• DFX extensions (work beginning in Q1 2023)
  • Will allow Azle/Kybra dfx.json to be as simple as Motoko or Rust, reducing complexity for devs, improving DX
• Remove the need for Candid file to be specified in dfx.json for Rust and custom canisters (should be coming in April 2023: https://forum.dfinity.org/t/automatically-generate-candid-from-rust-sources/5924/20)
  • Will remove 5-10 seconds from Azle/Kybra compile times
  • Will reduce Azle/Kybra build process complexity
  • Will reduce architecture complexities from having to compile for the developers' machines vs just wasm32-unknown-unknown (this has caused a bug before that was difficult to understand and fix)
• Increased cycle threshold for queries and composite queries
  • May allow for more complex Sudograph queries
• Message size limit increase or abstraction
• Cycle compensation at the protocol level (instead of burning all cycles, the protocol sets aside a percentage for the libraries installed into a canister, thus providing open source projects a stream of revenue)
• cdk public metadata standardized
  • We will be able to query any canister and know if it is an Azle or Kybra canister
  • Canister indexing services like the IC dashboard and icscan will be able to show canister totals by CDK, and could allow us to filter and sort through Azle, Kybra, Rust, Motoko and other canisters
• Wasi support
• WebSockets
• zkWasm on the DFINITY roadmap

As an app developer I want to deploy my app to a custom domain like sudograph.com.

Improves security

With SNS voting integration

For example, it would be awesome to click the little browser URL lock button (like in Chrome) and see the following certifications:

• DNS
• SSL
• All frontend assets signed by the subnet
• Wasm binary verified
• State changes to be verified (validity proofs)

Maybe a browser extension is a good first step.

Maybe through IP whitelisting, countries, etc.

If a subnet gets too large, it should automatically split into multiple subnets.

We should be able to choose the replication factor of the subnets we deploy our canisters to.

Maybe dfx canister logs

We don't want node providers to be able to read the state data of canisters they host. This might be accomplished through:

• Multi party computation
• Secure enclaves
• Homomorphic encryption