It does not attempt to be self-contained. Instead it exists partially to work out design patterns for microchain applications, and to help drive library development. It relies on user-level macros, which will eventually be replaced by language-level macros.
This iteration contains a command-driven interaction model. It uses commitment-based authentication with the following features:
Bank is created by owner who initializes the total supply of single currency.
Anyone can create an account.
Owner can grant funds to any account (reducing the bank's supply).
Account owners can transfer funds to other accounts (reducing their own balance).
Anyone can audit the bank, receiving confirmation that the audit provably passes if total of all accounts and bank's supply equals the initial supply.
Account authentication secrets are derived from public keys and bank id — minimizing need to expose 'private key' secrets with which account was created even locally while interacting with this chain.
NOTE: balances are not private, and neither is the bank's supply — so individuals could also audit the total supply on their own.
The song and dance separating pub-keys and accounts is partially present to drive development of tooling to help manage secrets and support data hygiene.
This is the successor to the bank demo.
It does not attempt to be self-contained. Instead it exists partially to work out design patterns for microchain applications, and to help drive library development. It relies on user-level macros, which will eventually be replaced by language-level macros.
This iteration contains a command-driven interaction model. It uses commitment-based authentication with the following features:
NOTE: balances are not private, and neither is the bank's supply — so individuals could also audit the total supply on their own.
The song and dance separating pub-keys and accounts is partially present to drive development of tooling to help manage secrets and support data hygiene.