• Tuesday

  Apr 19, 2022

  • Liquidation insurance can be offered by a protocol. JPEGd (NFT collateral platform) does 1%. You can tweak many options. Buy collateral back at an inflated price, deposit additional at a worse LTV, diversify…
  • UST is to LUNA as OHM is to (a gigantic treasury of diverse cryptocurrencies). That’s why I like olympus. It’s not a shock absorber that burns/mints to hold a stablecoin’s peg steady, it’s a backing that burns/mints the actual currency to maintain supply and PCV.
  • Bonds continued to have negative discount on olympus so I bypassed the bonding lockup by removing my ohm/eth liquidity on sushi, zapping the eth to gOHM, and staking the ohm to gohm.
  • SUI validates transactions individually (rather than lumped in a block) for efficiency and lower latency. https://docs.sui.io/learn/sui-compared#a-different-approach-to-state. Remember, it parallelizes everything as atomically as possible, down to individual transactions when it can determine they’re unrelated.
  • Aptos testnet.
    • https://medium.com/aptoslabs/aptos-incentivized-testnet-roadmap-209be695c77c
    • Phase 1: Validator registration may 13 and launches may 16. Limited to 100 validator nodes. They’ll provide the tooling via github, it’s called Genesis.
    • Phase 2: staking. They’ll test rewards, faucets, experiment with gas. Starts in June.
    • Phase 3: onchain governance and voting. Finalize state sync between validators. Starts July.
    • Phase 4: onboard many validators and add ddos protection. Start August.
  • Finished move tutorial, steps 4-8: https://github.com/diem/move/tree/main/language/documentation/tutorial.
    • assert!(<predicate>, <abort_code>);
    • You can define something like [addresses] NamedAddr = “0xCAFE” in Move.toml and then use it in the module like @NamedAddr.
    • Remember borrow_global() to read from global storage. And move_to(), exists(), borrow_global_mut(), acquires, move_from().
    • You don’t need to return something from a function, you can just modify a mutable ref.
    • Wrote some tests, designated with #[test].
    • Convert to generics, so BasicCoin has stuff like <phantom CoinType> for the Coin and Balance structs and then all functions (like deposit()) have <CoinType>. Then you can define something like MyCoin. Kinda like inheriting from ERC20 in solidity. Provides standards. Classes to inherit from. And overwrite, if desired.
    • Use the move prover to run Formal Verification checks (consistent checks on inputs and outputs). “move package prove” – make sure to specify the “aborts if” condition or “ensures” within the “spec”. Add “post” to compare a value after execution. The spec has access to all the input variables of the target function, by name.
      • You can add “pragma” for stuff like aborts_if_is_strict or aborts_if_is_partial.
      • You can even create a spec with generics that they become customized into other similar specs with overwrites for their different signatures.
  • Magnum6’ aptos blogs (https://mirror.xyz/magnum6.eth).
    • $200M, a16z.
    • Resources (structs) that have very clear ownership and deletion rules. That’s it.
    • Devnet resets every week.
    • Everything inside a struct inherits its abilities from the parent struct (unless redefined).
    • If you don’t explicitly put “move” or “copy” then it assumes “move” for resources (structs) and “copy” for scalars and primitives.
    • Remember address::module::resource
    • Coinbase and binance are already building on aptos devnet. https://aptoslabs.com/developers/.
    • Remember when you borrow_global() that each address can only have 0 or 1 of each resource. You can’t have 2 structs named the same thing under 1 account.
      • For my example ticketmaster app, each address can only own one Venue (unless you make it a vector). And each customer (address) can only own one ConcertTicket struct. Just make a wrapper struct (Wallet or something) with vector<ConcertTicket>.
    • And borrow acts as mutex. You can’t have two things borrow a resource at the same time and modify it.
    • _ to ignore a return variable. Technically it will ignore anything starting with _, so _foo will also be ignored.
    • Rust’s (effective) spread operator is [x].iter().chain(&[y]). Move does not have a spread operator.
    • AptosFramework. Very common dep. Contains modules like TestCoin (the native currency right now) for transferring and such. Here are the others: https://github.com/aptos-labs/aptos-core/tree/main/aptos-move/framework/aptos-framework/sources. The TestCoin module is <400 lines long.
    • Here is the stdlib (Signer, Vector, etc): https://github.com/aptos-labs/aptos-core/tree/main/aptos-move/framework/move-stdlib/sources.
    • Remember everything must be signed by the relevant parties. Obvious for a transfer, needs sender signature. What about recipient? This is implicit when they register that resource to their account. No followup signatures required to receive subsequent transfers.
  • Went through aptos dev docs (https://aptos.dev/).
    • Accounts have 16-byte addresses. They’re containers for modules (code) and resources (data).
    • Sequence number is the incremental transaction number for each account. Goes up by 1 for every transaction on that account. This is how you prevent replay attacks.
    • The native resources for an account (present at creation) are Authentication Key and Sequence Number (0).
    • Events are emitted for transactions (eg SentEvent and ReceivedEvent).
    • There’s a rest API to query accounts, transactions, events, etc. Eg: https://fullnode.devnet.aptoslabs.com/spec.html#/operations/get_events_by_event_handle
    • Two types of nodes: validator nodes and fullnodes. They both serve REST, run the mempool, forward transactions, run the aptos VM, has storage, and sync state. The difference is that ONLY validators participate in consensus.
    • Primary reasons to run your own node: perform transactions directly, query the REST api directly, listen for onchain events faster, MEV.
    • Gas works the same as eth. Atomic price for the atomic unit of computation, as well as max so that you can bound execution.
    • The aptos blockchain is a merkle tree. Aptos uses BFT for consensus.
    • A raw transaction will have the account address, private key, which move module is to be invoked and with which inputs (all bytecode), gas price, max gas, expiration time, sequence number, chain id.
    • First, aptos client (wallet or rest call or whatever) will send the raw transaction to a rest service on a fullnode or a validator. This will be forwarded among fullnodes until it reaches a validator. The validator will then perform initial checks (signature verification, doublespend, account balance, replay resistance, etc) on it within the node’s mempool. If they pass, it will forward to ALL other validator nodes’ mempools. Then a node will be elected as leader and that validator will pull the next transactions from its own mempool, create a block, and broadcast it to every other validator for verification. If consensus is reached, this block is accepted by all.