1. 06 Jun, 2019 1 commit
    • Jakob Botsch Nielsen's avatar
      Remove incoming_txs and outgoing_txs from contract view of chains · 90f0d1e4
      Jakob Botsch Nielsen authored
      This is much more realistic, as allowing contracts to efficiently access
      transaction histories for all addresses is extremely expensive. To do
      this, we
      * Add an account_balance operation in Chain instead
      * Change incoming_txs and outgoing_txs to compute transactions from
      * Require implementations to give a proof-relevant trace, and rework
        proofs to use these, as necessary
  2. 31 May, 2019 2 commits
  3. 14 May, 2019 1 commit
  4. 09 May, 2019 1 commit
  5. 05 May, 2019 2 commits
  6. 03 May, 2019 1 commit
  7. 02 May, 2019 1 commit
    • Jakob Botsch Nielsen's avatar
      Prove a property for the Congress contract · 1b1c9908
      Jakob Botsch Nielsen authored
      This proves a concrete property about any Congress contract deployed to
      a blockchain. More specifically, we show that the count of transactions
      sent out by any Congress contract will always be less than or equal to
      the total number of actions it has receive in "create proposal"
      Thus, this property is stated only over the transactions going in and
      out to the Congress contract.
      To prove this, we reason over incoming and outgoing transactions, the
      internal state of the congress and also the actions in the blockchain
  8. 01 May, 2019 2 commits
  9. 29 Apr, 2019 1 commit
  10. 27 Apr, 2019 2 commits
    • Jakob Botsch Nielsen's avatar
      Move ChainStep and ChainTrace to Type · 5221931a
      Jakob Botsch Nielsen authored
      This moves ChainStep and ChainTrace to type. The reason being that our
      proofs will depend on prefixes of traces and it will be very useful (if
      not required) to be able to match on the trace and the steps.
      ChainBuilderType is changed appropriately: now, an implementation just
      needs to prove that ChainTrace empty_env [] cur_env [] is inhabited.
      Thus, ChainTrace can basically be seen as one particular way to order
      the execution so that we reach a state. When it is inhabited, it thus
      means that there exists a proper way to order actions so that we reach
      the state we are in.
    • Jakob Botsch Nielsen's avatar
  11. 26 Apr, 2019 4 commits
  12. 25 Apr, 2019 6 commits
  13. 24 Apr, 2019 1 commit
  14. 23 Apr, 2019 1 commit
    • Jakob Botsch Nielsen's avatar
      Various refactorings and cleanups · f8adfa8c
      Jakob Botsch Nielsen authored
      * Remove BlockTrace and bake everything into ChainTrace
      * Simplify ChainTrace. Its signature is now
      ChainTrace : Environment -> list Action -> Prop.
      These changes will make it easier to reason over traces when proving
      properties about contracts. For one, we can now talk about prefixes of
      the entire chain without the weird distinction between block traces and
      chain traces.
  15. 22 Apr, 2019 4 commits
  16. 19 Apr, 2019 3 commits
    • Jakob Botsch Nielsen's avatar
      Update for dev Coq · 478221dd
      Jakob Botsch Nielsen authored
    • Jakob Botsch Nielsen's avatar
    • Jakob Botsch Nielsen's avatar
      Specify and prove an initial blockchain semantics · 71ea5d00
      Jakob Botsch Nielsen authored
      This specifies an initial version of blockchain semantics. The semantics
      are specified as several relations:
      ChainStep :
        Environment -> Action -> Tx ->
        Environment -> list Action ->
      This relation captures the semantics of a single step/action in the
      chain. Such an action can either be a transfer, contract deployment or
      contract call. It specifies that when an action is executed in some
      starting environment, then the blockchain records a transaction (Tx) on
      the chain and performs certain updates to the environment. Finally, the
      step also results in possible new actions to be executed due to contract
      An environment is for now simply a Chain (which contracts can interact
      with) and a collection of contracts that have been deployed to some
      addresses. The Chain contains various useful operations for contracts
      such as the current block number or ability to query transactions and
      user balances.
      For example, for a simple transfer action w...
  17. 19 Mar, 2019 2 commits
  18. 12 Mar, 2019 1 commit
    • Jakob Botsch Nielsen's avatar
      Abstract ChainBuilder and rename LocalChainEnvironment -> LocalChainBuilder · 8038826a
      Jakob Botsch Nielsen authored
      The ChainBuilder represents the full implementation of a blockchain
      containing all operations (such as adding blocks) and state (such as
      full contracts with their receive functions). Such a value is
      convertible to a Chain (but not vice versa). This is where we will state
      general properties about how the block chain behaves temporally.
  19. 10 Mar, 2019 1 commit
    • Jakob Botsch Nielsen's avatar
      Refactor finite map/finite sets and prove map-list/set-list equality · 5e814944
      Jakob Botsch Nielsen authored
      * Pull the functionality we need into a Containers.v file that takes
        care of including the proper implementations of fmaps and fsets.
        Additionally, this file defines notation/new names.
      * Stop using map/set notation for operations. This conflicts with
        lists/record-set and is generally a head-ache.
      * Switch to lists instead of AVL trees for the sets and maps. This
        allows us to prove (assuming proof irrelevance) what we need:
        FSet.of_list (FSet.elements x) = x. Prove this and the equivalent for
        fin maps.
      * Do not use program instances in Oak.v. We can do with instances which
        generate a lot less bloat.
  20. 08 Mar, 2019 3 commits
    • Jakob Botsch Nielsen's avatar
      Add Blockchain.get_contract_interface and create_deployment · 11c14413
      Jakob Botsch Nielsen authored
      These functions allow interacting with contracts in a strongly-typed
      manner without having to serialize/deserialize manually.
      Also adjust test to use these.
    • Jakob Botsch Nielsen's avatar
      Add a working example using the Congress · 0bcb6c0c
      Jakob Botsch Nielsen authored
      This adds a small example that uses a local blockchain to deploy a
      congress and do a transfer with it.
      Also fixes bugs to make this work.
    • Jakob Botsch Nielsen's avatar
      Implement execution in LocalBlockChain · 357cd8df
      Jakob Botsch Nielsen authored
      This implements a depth first execution of chain actions with support
      for deploying contracts from contracts and calling into other contracts
      recursively. To support these things, contracts need to exhibit a
      bijection of their types from and to OakValue. This machinery is modeled
      with type classes. Then, use this to avoid having to store strongly
      typed contracts anywhere; instead, a contract can be converted to a
      WeakContract instance (using a coercion). The WeakContract verifies that
      messages and states serialize/deserialize correctly and then passes
      everything along to the strongly typed contract under the hood.