Merge pull request #1478 from dedis/bc

Goodbye OmniLedger, hello ByzCoin

.travis.yml

@@ -4,7 +4,6 @@ dist: trusty
 
 node_js:
   - "lts/*"
-  - "8"
 
 env:
   - TEST_DIR=cothority

README.md

@@ -52,8 +52,8 @@ The source code for this stable branch is
 [here](https://github.com/dedis/cothority/tree/v2).
 
 During 2018, we hope to bring you the following new pieces:
-- Cross platform mobile application to interact with the cisc and pop services
-- Omniledger implementation using key/value pair storage and protected by darcs
+- Cross platform mobile application to interact with the pop service
+- ByzCoin implementation using key/value pair storage and protected by darcs
 
 Other pieces we hope to achieve in 2018:
 - Distributed internet archival functionality
@@ -89,7 +89,7 @@ it up as follows:
 +--------------------------+------------+--------------------------+
 |     Onchain-Secrets      |APPLICATIONS|                          |
 |                          +------------+     Proof of Personhood  |
-|       Omniledger                                                 |
+|       ByzCoin                                                    |
 |                               Status            E-voting         |
 | CISC Identity SkipChain                                          |
 +------------------------+---------------+-------------------------+

omniledger/Contracts.md → byzcoin/Contracts.md

@@ -1,19 +1,19 @@
 Navigation: [DEDIS](https://github.com/dedis/doc/tree/master/README.md) ::
 [Cothority](https://github.com/dedis/cothority/tree/master/README.md) ::
 [Building Blocks](https://github.com/dedis/cothority/tree/master/doc/BuildingBlocks.md) ::
-[OmniLedger](README.md) ::
+[ByzCoin](README.md) ::
 Contracts and Instances
 
 # Contracts and Instances
 
-A contract in OmniLedger is similar to a smart contract in Ethereum, except that
+A contract in ByzCoin is similar to a smart contract in Ethereum, except that
 it is pre-compiled in the code and all nodes need to have the same version of
 the contract available in order to reach consensus. Or, if there are variations
 in the implementation of the contract, the output of the various implementations
 must be equal.
 
 A contract can spawn new instances that are tied to another contract type. All
-instances are stored in the global state of OmniLedger. Every instance points
+instances are stored in the global state of ByzCoin. Every instance points
 to exactly one contract. An easy interpretation is to think of a contract as
 a class and the instance as an object instantiated from that class. Or, in Go,
 as the instance being the values of the `struct` and the contract being all
@@ -37,7 +37,7 @@ clarity):
   - `Args`: `{"Roster": NewRoster}`
 - `Signatures`: `[Sig1]`
 
-OmniLedger will do the following:
+ByzCoin will do the following:
 
 1. find the Darc instance using the `InstanceID`.
 2. create a `DarcRequest` using the `InstanceID` and the `Args`
@@ -50,7 +50,7 @@ A contract is always pre-compiled into every node and has the following
 method signature:
 
 ```go
-type OmniLedgerContract func(coll CollectionView, tx Instruction, inCoins []Coin) (sc []StateChange, outCoins []Coin, err error)
+type ByzCoinContract func(coll CollectionView, tx Instruction, inCoins []Coin) (sc []StateChange, outCoins []Coin, err error)
 ```
 
 Input:
@@ -84,7 +84,7 @@ in the second `ClientTransaction` will see all changes applied from the first
 
 ## Instance Structure
 
-Every instance in OmniLedger is stored with the following information in the
+Every instance in ByzCoin is stored with the following information in the
 global state:
 
 - `InstanceID` is a globally unique identifier of that instance, composed
@@ -97,7 +97,7 @@ receives an instruction from the client
 ## Interaction between Instructions and Instances
 
 Every instruction sent by a client indicates the `InstanceID` it is sent to.
-OmniLedger will start by verifying the authorization as described above, then
+ByzCoin will start by verifying the authorization as described above, then
 use the `InstanceID` to look up the responsible contract for this instance and
 then send the instruction to that contract. A client can call an instance with
 one of the following three basic instructions:
@@ -110,44 +110,44 @@ spawn new instances.
 
 # Existing Contracts
 
-In the OmniLedger service, the following contracts are pre-defined:
+In the ByzCoin service, the following contracts are pre-defined:
 
 - `GenesisReference` - points to the genesis configuration
-- `Config` - holds the configuration of OmniLedger
+- `Config` - holds the configuration of ByzCoin
 - `Darc` - defines the access control
 
-To extend OmniLedger, you will have to create a new service that defines new
-contracts that will have to be registered with OmniLedger. An example is
+To extend ByzCoin, you will have to create a new service that defines new
+contracts that will have to be registered with ByzCoin. An example is
 [EventLog](../../eventlog) that defines a contract.
 
 ## Genesis Configuration
 
 The special `InstanceID` with 64 x 0x00 bytes is the genesis configuration
 pointer that has as the data the `DarcID` of the genesis Darc. This instance
-is unique as it defines the basic running configuration of OmniLedger. The
+is unique as it defines the basic running configuration of ByzCoin. The
 Darc it points to will delegate authorizations to spawn new instances to
 other Darcs, who can themselves delegate further.
 
 The following two contracts can only be instantiated once in the whole system:
 
 - `GenesisReference`, which has the `InstanceID` of 64 x 0x00 and points to the
 genesis Darc
-- `Config`, which defines the basic configuration of OmniLedger:
+- `Config`, which defines the basic configuration of ByzCoin:
   - `Roster` is the list of all nodes participating in the consensus
 
 ### Spawn
 
 The `Config` contract can spawn new Darcs or any other type of instances that
-are available to OmniLedger.
+are available to ByzCoin.
 
 ### Invoke
 
 - `Config_Update` - stores a new configuration
 
 ## Darc Contract
 
-The most basic contract in OmniLedger is the `Darc` contract that defines the
-access rules for all clients. When creating a new OmniLedger blockchain, a
+The most basic contract in ByzCoin is the `Darc` contract that defines the
+access rules for all clients. When creating a new ByzCoin blockchain, a
 genesis Darc instance is created, which indicates what instructions need which
 signatures to be accepted.
 
@@ -165,7 +165,7 @@ to invoke methods on it later.
 ### Invoke
 
 The only method that a client can invoke on a Darc instance is `Evolve`, which
-asks OmniLedger to store a new version of the Darc in the global state.
+asks ByzCoin to store a new version of the Darc in the global state.
 
 ### Delete
 
@@ -177,7 +177,7 @@ global state.
 Here is a short list of possible future contracts that are imaginable. But
 your coding skills set the limits:
 
-- OmniLedger Configuration
+- ByzCoin Configuration
   - create new configuration
   - Add or remove nodes
   - Change the block interval time

omniledger/DataStructures.md → byzcoin/DataStructures.md

@@ -1,28 +1,28 @@
 Navigation: [DEDIS](https://github.com/dedis/doc/tree/master/README.md) ::
 [Cothority](https://github.com/dedis/cothority/tree/master/README.md) ::
 [Building Blocks](https://github.com/dedis/cothority/tree/master/doc/BuildingBlocks.md) ::
-[OmniLedger](README.md) ::
+[ByzCoin](README.md) ::
 Data Structures
 
 # Data Structures
 
-This document gives an overview of the basic data structures used in OmniLedger:
+This document gives an overview of the basic data structures used in ByzCoin:
 
 - [ClientTransaction](#clienttransaction) is sent by a client to one or more
 nodes and holds one or more Instructions:
 - [Instruction](#instruction) is a basic building block that will be executed
-in OmniLedger. It has either a `Spawn`, `Invoke`, or a `Delete` command. Once
+in ByzCoin. It has either a `Spawn`, `Invoke`, or a `Delete` command. Once
 accepted, every instruction creates zero or more `StateChanges`:
 - [StateChange](#statechange) are collected and define how the global state will
 change.
 - [Darc](#darc) control access to executing Instructions. The signers of an
 Instruction must satisfy one of the rules in the associated Darc.
 - [Proof](#proof) shows to a client that his instruction has been accepted by
-OmniLedger.
+ByzCoin.
 
 ## ClientTransaction
 
-If a client needs a set of instructions to be applied atomically by OmniLedger,
+If a client needs a set of instructions to be applied atomically by ByzCoin,
 it can send more than one instruction in a ClientTransaction. This structure
 has the following format:
 
@@ -96,7 +96,7 @@ instructions to the corresponding contracts and/or objects. Each call to a
 contract/object will return 0 or more StateChanges that define how to update the
 state of the collection.
 
-OmniLedger will take care that the following instruction/StateChanges are
+ByzCoin will take care that the following instruction/StateChanges are
 respected. *This might be too restrictive*:
 - Spawn: only Create-Actions
 - Invoke: only Update-Action on the invoked object
@@ -120,8 +120,8 @@ message StateChange {
 
 ## Proof
 
-The proof in OmniLedger proves the absence or the presence of a key in the state
-of the given OmniLedger. If the key is present, the proof also contains the value
+The proof in ByzCoin proves the absence or the presence of a key in the state
+of the given ByzCoin. If the key is present, the proof also contains the value
 of the key, as well as the contract that wrote it, and the DarcID of the Darc
 that controls access to it.
 

omniledger/README.md → byzcoin/README.md

@@ -1,29 +1,29 @@
 Navigation: [DEDIS](https://github.com/dedis/doc/tree/master/README.md) ::
 [Cothority](https://github.com/dedis/cothority/tree/master/README.md) ::
 [Building Blocks](https://github.com/dedis/cothority/tree/master/doc/BuildingBlocks.md) ::
-OmniLedger
+ByzCoin
 
-# OmniLedger
+# ByzCoin
 
-This implementation of OmniLedger has its goal to implement the protocol
-described in the [OmniLedger Paper](https://eprint.iacr.org/2017/406.pdf).
+This implementation of ByzCoin has its goal to implement the protocol
+described in the [ByzCoin Paper](https://eprint.iacr.org/2017/406.pdf).
 As the paper is only describing the network interaction and very few of the
 details of how the transactions themselves are handled, we will include
 them as seem fit.
 
-This document describes the part of OmniLedger that are implemented and how to
+This document describes the part of ByzCoin that are implemented and how to
 use them. It should grow over time as more parts of the system are implemented.
 
 ## Overview
 
 Here is a graphical overview of the current implementation in the cothority
 framework:
 
-![OmniLedger Implementation](Omniledger.png?raw=true "OmniLedger")
-As an svg: [OmniLedger Implementation](Omniledger.svg). This image has been
+![ByzCoin Implementation](ByzCoin.png?raw=true "ByzCoin")
+As an svg: [ByzCoin Implementation](ByzCoin.svg). This image has been
 created with https://draw.io and can be imported there.
 
-Our OmniLedger service currently implements:
+Our ByzCoin service currently implements:
 
 1. multiple transactions per block
 2. queuing of transactions at each node and periodic creation of a new
@@ -36,13 +36,13 @@ The following points are scheduled to be done before end of '18:
 5. sharding of the nodes
 6. inter-shard transactions
 
-Items 5 and 6 are the 'real' OmniLedger improvements as described in the
-[OmniLedger Paper](https://eprint.iacr.org/2017/406.pdf).
+Items 5 and 6 are the 'real' ByzCoin improvements as described in the
+[ByzCoin Paper](https://eprint.iacr.org/2017/406.pdf).
 
 ## Transaction collection and View Change
 
 Transactions can be submitted by end-users to any conode in the roster for
-the Skipchain that is holding the OmniLedger.
+the Skipchain that is holding the ByzCoin.
 
 At the beginning of each block creation, the leader launches a protocol to
 contact all the followers in parallel and to request the outstanding
@@ -71,13 +71,13 @@ synchronise and replay blocks to compute the most up-to-date leader.
 
 # Structure Definitions
 
-Following is an overview of the most important structures defined in OmniLedger.
+Following is an overview of the most important structures defined in ByzCoin.
 For a more programmatic description of these structures, go to the
 [DataStructures](DataStructures.md) file.
 
 ## Skipchain Block
 
-Whenever OmniLedger stores a new Skipchain Block, the header will only contain
+Whenever ByzCoin stores a new Skipchain Block, the header will only contain
 hashes, while the ClientTransactions will be stored in the body. This allows
 for a reduced proof size.
 
@@ -89,7 +89,7 @@ Block header:
 Block body:
 - List of all ClientTransactions
 
-## Smart Contracts in OmniLedger
+## Smart Contracts in ByzCoin
 
 A contract defines how to interpret the methods sent by the client. It is
 identified by the contractID which is a string pointing to a given contract.
@@ -115,13 +115,13 @@ The contracts are compiled into the conode binary. A set of conodes making
 up a cothority may have differing implementations of a given contract,
 but if they do not create the same output StateChanges, the cothority might not
 be able to reach the threshold of agreeing conodes in order to commit the
-transactions onto the OmniLedger. If one conode is creating differing contract outputs
+transactions onto the ByzCoin. If one conode is creating differing contract outputs
 (for example, it is cheating), it's output will not be integrated into the
 global shared state.
 
 ## From Client to the Collection
 
-In OmniLedger we define the following path from client instructions to
+In ByzCoin we define the following path from client instructions to
 global state changes:
 
 * _Instruction_ is one of Spawn, Invoke or Delete that is called upon an
@@ -130,7 +130,7 @@ existing object
 * _StateChange_ is calculated at the leader and verified by every node. It
 contains the new key/contractID/value triplets to create/update/delete.
 
-A block in OmniLedger contains zero or more OmniLedgerTransactions. Every
+A block in ByzCoin contains zero or more ByzCoinTransactions. Every
 one of these transactions can be valid or not and will be marked as such by
 the leader. Every node has to verify whether it accepts or refuses the
 decisions made by the leader.

omniledger/service/api.go → byzcoin/api.go

@@ -1,4 +1,4 @@
-package service
+package byzcoin
 
 import (
 	"bytes"
@@ -9,23 +9,23 @@ import (
 	"github.com/dedis/protobuf"
 
 	"github.com/dedis/cothority"
-	"github.com/dedis/cothority/omniledger/darc"
-	"github.com/dedis/cothority/omniledger/darc/expression"
+	"github.com/dedis/cothority/byzcoin/darc"
+	"github.com/dedis/cothority/byzcoin/darc/expression"
 	"github.com/dedis/cothority/skipchain"
 	"github.com/dedis/onet"
 )
 
 // ServiceName is used for registration on the onet.
-const ServiceName = "OmniLedger"
+const ServiceName = "ByzCoin"
 
-// Client is a structure to communicate with the OmniLedger service.
+// Client is a structure to communicate with the ByzCoin service.
 type Client struct {
 	*onet.Client
 	ID     skipchain.SkipBlockID
 	Roster onet.Roster
 }
 
-// NewClient instantiates a new Omniledger client.
+// NewClient instantiates a new ByzCoin client.
 func NewClient(ID skipchain.SkipBlockID, Roster onet.Roster) *Client {
 	return &Client{
 		Client: onet.NewClient(cothority.Suite, ServiceName),
@@ -44,8 +44,8 @@ func NewClientKeep(ID skipchain.SkipBlockID, Roster onet.Roster) *Client {
 	}
 }
 
-// NewOmniledger sets up a new OmniLedger instance.
-func NewOmniledger(msg *CreateGenesisBlock, keep bool) (*Client, *CreateGenesisBlockResponse, error) {
+// NewLedger sets up a new ByzCoin ledger.
+func NewLedger(msg *CreateGenesisBlock, keep bool) (*Client, *CreateGenesisBlockResponse, error) {
 	var c *Client
 	if keep {
 		c = NewClientKeep(nil, msg.Roster)
@@ -69,7 +69,7 @@ func (c *Client) AddTransaction(tx ClientTransaction) (*AddTxResponse, error) {
 }
 
 // AddTransactionAndWait adds a transaction and will wait for it to be included
-// in omniledger, up to a maximum of wait block intervals. It does not return
+// in the ledger, up to a maximum of wait block intervals. It does not return
 // any feedback on the transaction. The Client's Roster and ID should be
 // initialized before calling this method (see NewClientFromConfig).
 func (c *Client) AddTransactionAndWait(tx ClientTransaction, wait int) (*AddTxResponse, error) {
@@ -105,7 +105,7 @@ func (c *Client) GetProof(key []byte) (*GetProofResponse, error) {
 }
 
 // GetGenDarc uses the GetProof method to fetch the latest version of the
-// Genesis Darc from OmniLedger and parses it.
+// Genesis Darc from ByzCoin and parses it.
 func (c *Client) GetGenDarc() (*darc.Darc, error) {
 	p, err := c.GetProof(NewInstanceID(nil).Slice())
 	if err != nil {
@@ -154,7 +154,7 @@ func (c *Client) GetGenDarc() (*darc.Darc, error) {
 }
 
 // GetChainConfig uses the GetProof method to fetch the chain config
-// from OmniLedger.
+// from ByzCoin.
 func (c *Client) GetChainConfig() (*ChainConfig, error) {
 	p, err := c.GetProof(NewInstanceID(nil).Slice())
 	if err != nil {
@@ -180,7 +180,7 @@ func (c *Client) GetChainConfig() (*ChainConfig, error) {
 	return config, nil
 }
 
-// WaitProof will poll OmniLedger until a given instanceID exists.
+// WaitProof will poll ByzCoin until a given instanceID exists.
 // It will return the proof of the instance created. If value is
 // non-nil, it will wait for the value of the proof to be equal to
 // the value.