This repository has been archived by the owner on Jun 26, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Integrate consensus and network ledger to a trivial ledger.
The README describes the demo.
- Loading branch information
Showing
14 changed files
with
2,913 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,53 @@ | ||
Apache License | ||
|
||
Version 2.0, January 2004 | ||
|
||
http://www.apache.org/licenses/ | ||
|
||
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION | ||
|
||
1. Definitions. | ||
|
||
"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document. | ||
|
||
"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License. | ||
|
||
"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity. | ||
|
||
"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License. | ||
|
||
"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files. | ||
|
||
"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types. | ||
|
||
"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below). | ||
|
||
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof. | ||
|
||
"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution." | ||
|
||
"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work. | ||
|
||
2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. | ||
|
||
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed. | ||
|
||
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions: | ||
|
||
You must give any other recipients of the Work or Derivative Works a copy of this License; and | ||
You must cause any modified files to carry prominent notices stating that You changed the files; and | ||
You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and | ||
If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License. | ||
|
||
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. | ||
5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions. | ||
|
||
6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file. | ||
|
||
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License. | ||
|
||
8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages. | ||
|
||
9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability. | ||
|
||
END OF TERMS AND CONDITIONS |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
Copyright 2019 IOHK | ||
|
||
Licensed under the Apache License, Version 2.0 (the "License”). You may not use | ||
this file except in compliance with the License. You may obtain a copy of the | ||
License at http://www.apache.org/licenses/LICENSE-2.0.txt | ||
|
||
Unless required by applicable law or agreed to in writing, software distributed | ||
under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR | ||
CONDITIONS OF ANY KIND, either express or implied. See the License for the | ||
specific language governing permissions and limitations under the License. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,233 @@ | ||
# About | ||
|
||
This project defines a simple ledger layer, and integrates it to the Cardano | ||
[consensus and network | ||
layers](https://github.com/input-output-hk/ouroboros-network) so that a node can | ||
be run. This project is intended to serve as a reference for those who want to | ||
integrate their own ledgers to the reusable parts of Cardano. | ||
|
||
We present next a high level description of the ledger logic that this project | ||
implements, how to run a demo, and how the code is organized. | ||
|
||
# The Oddchain | ||
|
||
We define a ledger layer for an _oddchain_: a chain that consists of odd numbers | ||
only. Blocks of the _oddchain_ consists of a sequence of odd numbers that are | ||
strictly increasing of decreasing, according to the current _phase_. The _phase_ | ||
determines: | ||
|
||
- Whether the numbers inside a block should decrease or increase | ||
- A bound for the numbers in the block. If the phase is _decreasing_ then the | ||
phase determines the upper bound, if the phase is increasing then the phase | ||
determines the lower bound. | ||
|
||
For instance, if the current phase is decreasing and has a bound of 10, then a | ||
block produced in that phase must contain decreasing sequences of odd numbers | ||
smaller than 10. | ||
|
||
The bound of a phase changes after each block, and the sign of the phase | ||
(decreasing or increasing) is flipped after each epoch. | ||
|
||
## Running the demo | ||
|
||
The demo can run multiple nodes in a local machine. It shouldn't be too hard to | ||
modify this project to support running nodes in different machines, but for the | ||
sake of simplicity we do not implement this functionality. | ||
|
||
This project has been tested on Linux only at the moment. If you have access to | ||
a machine with a different OS feel free to try this out as well, and submit a PR | ||
with the changes needed to run this in different platforms :heart:. | ||
|
||
If you have [`stack`](https://docs.haskellstack.org/en/stable/README/) and | ||
[`tmux`](https://github.com/tmux/tmux/wiki) installed and use a Unix based | ||
operating system, we provide a simple script to start multiple nodes and | ||
clients. | ||
|
||
First make sure that you run: | ||
|
||
```sh | ||
stack build | ||
``` | ||
|
||
After that, inside a `tmux` session run: | ||
|
||
```sh | ||
./oddchain/demo.hs --numNodes 3 | ||
``` | ||
|
||
The number of nodes can be between 1 and 3. If you have enough screen real state | ||
you could try modifying the script to allow a larger number of nodes. | ||
|
||
This will start `numNodes` nodes and `numNodes` clients (wallets). The nodes | ||
communicate to each other and issue blocks according to the Byzantine Fault | ||
Tolerant (BFT) consensus protocol, whereas the clients submit random | ||
transactions to their corresponding nodes. | ||
|
||
What you should see is a terminal split in `numNodes * 2` panes, where the top | ||
layer shows the nodes' output, and the bottom layer shows the clients' (simple | ||
wallet) output. At this bottom layer you should see the blocks produced being | ||
reported, and of course, all the clients should agree on the blocks they see | ||
:slightly_smiling_face:. | ||
|
||
### Running nodes individually | ||
|
||
If you wish to run nodes individually, this can be done as follows: | ||
|
||
```sh | ||
stack exec oddnode -- \ | ||
--numberOfCoreNodes 3 \ | ||
--nodeId 2 \ | ||
--enableTracers Consensus \ | ||
--startTimeString '2020-03-18 11:27:32.925865787 UTC' | ||
``` | ||
|
||
here: | ||
|
||
- `numberOfCoreNodes` determines how many core nodes are in the network. | ||
- `nodeId` specifies the node id, which must be between 0 and `numberOfCoreNodes - 1`. | ||
- `enableTracers` allows to enable different tracers. See `OddNode.NodeTracer` | ||
for available options. | ||
- `startTimeString` specifies the time at which the blockchain started. It is | ||
**crucial** that all nodes in the network have the same start time. | ||
|
||
|
||
To run a client (wallet) that submits transaction to its corresponding node you | ||
can use: | ||
|
||
```sh | ||
stack run oddwallet -- --nodeId 2 --enabledTracers Rolls | ||
``` | ||
|
||
where the `nodeId` and `enabledTracers` parameters have the same meaning above | ||
described. The data type `OddWallet.WalletTracer` defines the available tracers | ||
for the wallet. | ||
|
||
## Structure of the project | ||
|
||
Directory `app` contain the main files for the node and wallet. | ||
|
||
The entry point for running a node can be found in `src/OddNode.oddRun`. See the | ||
docstring in this function for some caveats that apply to this demo. | ||
|
||
Function `oddRun` requires several | ||
[`ouroboros-consensus`](https://github.com/input-output-hk/ouroboros-network/tree/master/ouroboros-consensus) | ||
instances, which are defined in `module OddChain`. The major instances one has to define are: | ||
|
||
- `BlockProtocol` type instance. This determines the protocol that the blocks | ||
support. | ||
- `BlockSupportsProtocol` class instance. This determines how to obtain the data | ||
required to validate the given header according to the consensus rules | ||
(`ValidateView`) and how to obtain the data required to select among competing | ||
chains (`SelectView`). | ||
- `LedgerSupportsProtocol` class instance. This links the ledger to the | ||
protocol, by having the former giving the necessary information to the latter. | ||
The consensus algorithm uses this information to determine if the node should | ||
produce a block (`LedgerView`). For the BFT protocol, the ledger view is just | ||
`()`, since leader election is based on a round-robin schedule. More | ||
sophisticated consensus protocols, such as | ||
[Praos](https://iohk.io/en/research/library/papers/ouroboros-praosan-adaptively-securesemi-synchronous-proof-of-stake-protocol/), | ||
might require other information like some approximation of the stake | ||
distribution. | ||
- `UpdateLedger` class instance. This defines how blocks can be applied to the | ||
ledger state to update it. This is where the ledger logic lives. | ||
- `ApplyTx` class instance. Similar to `UpdateLedger`, this instance defines how | ||
to different transactions affect the ledger state. This instance is used by | ||
the mempool. Property `Test.OddChain.prop_mempool` defines the relation that | ||
is expected to hold between the instances of these type classes. Be aware that | ||
there might be other properties that aren't currently captured in the tests. | ||
- `RunNode` instance. This defines, among other things, functions to: | ||
- forge blocks when the node is the leader (given, among other things, a | ||
sequence of transactions) | ||
- determine if the header matches the body | ||
- serialize and deserialize data (blocks, headers, transactions, etc) | ||
|
||
In addition, the consensus layer does not prescribe which encoding to use. We | ||
use [`CBOR`](https://tools.ietf.org/html/rfc7049) for this purpose, and the | ||
`ToCBOR`/`FromCBOR` instances are defined in the `OddChain` module as well. | ||
|
||
The module `OddChain` defines `HasHeader` instances for both odd blocks and odd | ||
block headers. This is required since at certain stages the consensus layer | ||
would have either the whole block available or only the headers. | ||
|
||
Besides these instances, the `OddChain` module contains a definition of the | ||
block type for the odd chain, together with a definition of the ledger state. | ||
When defining the ledger state is **important** that that the ledger state can | ||
retrieve the header hash of the last applied block (see the instance of function | ||
`ledgerTipPoint`). | ||
|
||
The `OddWallet` module contains the implementation of a simple wallet that | ||
submits random transactions to the node it is connected to. | ||
|
||
Tests for the implementation are defined in the following modules: | ||
|
||
- `Test.ThreadNet.OddChain` which contains: | ||
- a test to check that the consensus layer is behaving as expected for the odd | ||
chain instance (see `prop_simple_oddchain_convergence`) | ||
|
||
- `Test.OddChain` which contains: | ||
- roundtrip tests to make sure serialization and deserialization work as | ||
expected. | ||
- header encoding tests, to make sure that we correctly implement | ||
`nodeEncodeBlockWithInfo`. | ||
- ledger property tests (see next section). | ||
|
||
## Properties that the ledger layer should satisfy | ||
|
||
### Relation between `UpdateLedger` and `ApplyTx` instances | ||
|
||
Applying a sequence of transactions should result in the same state as applying | ||
those transactions as part of a block's payload. See | ||
`Test.OddChain.prop_mempool`. | ||
|
||
### Re-applying succeeds if applying does | ||
|
||
Function `reapplyLedgerBlock` should skip block payload validation but update | ||
the ledger state. So this means that if `applyLedgerBlock` succeeded, then | ||
`reapplyLedgerBlock` should succeed as well and they should end up in the same | ||
state. | ||
|
||
Functions `applyTx` and `reapplyTx` should also satisfy this property. | ||
|
||
### Lemmas | ||
|
||
The following lemmas are checked by consensus when assertions are enabled. See | ||
`flag asserts`. See also [this issue](). | ||
|
||
#### Relation between `anachronisticProtocolLedgerView` and `applyChainTick` | ||
|
||
The anachronistic protocol ledger view returns the same view as the one obtained | ||
by applying chain tick with the given slot. Formally: | ||
|
||
``` | ||
for all ledgerTipSlot st <= s <= L , | ||
anachronisticProtocolLedgerView cfg st s | ||
== protocolLedgerView (applyChainTick cfg s st) | ||
``` | ||
|
||
where `L` is the maximum number of slots the ledger can look ahead (for instance | ||
for Byron this is `2k`). | ||
|
||
#### Relation between block application and chain tick | ||
|
||
Applying a block and applying the chain tick result in the same protocol ledger | ||
view. Formally: | ||
|
||
|
||
``` | ||
protocolLedgerView (applyLedgerBlock cfg blk state) | ||
== protocolLedgerView (applyChainTick cfg (blockSlot blk) state) | ||
``` | ||
|
||
### Relation between applying a block, chain ticks, and applying transactions | ||
|
||
Applying a **valid** block `blk` on state `st` should result in the same state | ||
as ticking the ledger state by the block slot, and then applying the | ||
transactions inside the block. Note that here **validity** of block is crucial. | ||
If the block is invalid in the given state, then we can't say anything about the | ||
equality. Formally, for all valid blocks: | ||
|
||
``` | ||
applyLedgerBlock cfg blk st | ||
== repeatedlyM (applyTx cfg) (extractTxs blk) | ||
(applyChainTick cfg (blockSlot blk) st) | ||
``` |
Oops, something went wrong.