[Epic] Prototype transaction model

[acoglio]

🚀 Feature

Even though the design of the new transaction model has not been finalized yet, it seems prudent to start building some initial version of it, along the lines of the approach to explicitly construct Transaction values described in the transaction model document. This involves defining (initial) data types for records, transitions, etc. (in the Leo stdlib) and implementing a 'transaction builder' as part of the Leo CLI.

While some of these features may change as we figure out an improved model, it is likely that this initial prototype will uncover, and make us solve, some general issues. Furthermore, it will give us an opportunity to try and implement example applications, which will help inform the evolution of the design.

[d0cd]

Linking some motivating examples: https://github.com/AleoHQ/leo-examples
From an initial look at the the ERC example (without approvals), it seems like we may also need the following features.

• Bit/byte conversions (done in Leo, need support in snarkVM)
• Two new annotations: @transition. Add @transaction later.
• Multiple entrypoints for a program (Supported)
• Result semantics (Rust)? (Not necessary).
• We may not need explicit data types for transitions and transactions, so long as the transaction builder can automatically process functions with the above annotations
• Issue [Change] Update State Record Model for Testnet 2 #1485 (high priority, quick)

Note: these are just some rough ideas off of some examples I worked on.

At a high level, the first iteration of the programming model will be an explicit realization of the record model. In other words, Leo applications on Aleo are simply collections of programs, that consist of functions that consume and process Records.
It will be a very functional style of programming and will not explicitly support public/global state.

[d0cd]

Tasks required for this epic are as follows:

• Resolve issue [Change] Update State Record Model for Testnet 2 #1485 (pausing for now, as we will likely remove this mechanism for describing program state)
• Support for @transition annotation. @d0cd
  • Should allow 2 Records as in function inputs, but also any number of other args

• Ensure that input and output types are Records with arity <= 2
• May need to add more checks/transformations as they come

• to_bytes for all scalar types (in Leo).
• gadgets for to_bytes (in snarkVM).
• Multiple entrypoints for a program. (May not necessarily be needed for this epic. Revisit later) @0rphon
• Records in stdlib. @d0cd
  • This should be moved to prelude so it is auto-imported.
• Model for encoding and decoding data into Records.

• For now, this is an explicit model that uses to/from_bytes in stdlib, which imposes certain restrictions and has additional constraint costs. In the future, we may consider more flexible options (e.g. allowing users to invoke foreign functions.)

• CLI tool for packaging transitions/transactions
• blake2s in unstable needs to be removed
• Ensure that the NFT application works.

Please feel free to assign yourself to any of the tasks by placing your handle next to it.

Relevant branches

• https://github.com/AleoHQ/snarkVM/tree/feature/staging-testnet2
• https://github.com/AleoHQ/leo/tree/feature/transaction-builder
• https://github.com/AleoHQ/leo/tree/feature/staging-testnet2

[collinc97]

The transition function in Leo v1.6.2 represents the model for interacting with multiple records in Leo.