All Projects → sigp → cbc-casper-js

sigp / cbc-casper-js

Licence: AGPL-3.0 license
JS implementation of Vlad Zamfir's CBC Casper TFG

Programming Languages

javascript
184084 projects - #8 most used programming language

Projects that are alternatives of or similar to cbc-casper-js

toychain
A minimalistic blockchain consensus implemented and verified in Coq
Stars: ✭ 103 (+390.48%)
Mutual labels:  consensus
minority
Ethereum 2.0 node multiplexer between consensus and execution
Stars: ✭ 94 (+347.62%)
Mutual labels:  consensus
anychaindb
AnychainDB is fast, distributed, blockchain database based on Tendermint and MongoDB
Stars: ✭ 16 (-23.81%)
Mutual labels:  consensus
go-cita
A Go implementation of CITA. https://docs.nervos.org/cita
Stars: ✭ 25 (+19.05%)
Mutual labels:  consensus
boki
Boki: Stateful Serverless Computing with Shared Logs [SOSP '21]
Stars: ✭ 39 (+85.71%)
Mutual labels:  consensus
gttc
Official Go implementation of maro (TTC), A Decentralized and Incentivized Social Networking Protocol
Stars: ✭ 117 (+457.14%)
Mutual labels:  consensus
vrrm
rough code for running consensus
Stars: ✭ 18 (-14.29%)
Mutual labels:  consensus
raftor
Distributed chat system built with rust
Stars: ✭ 31 (+47.62%)
Mutual labels:  consensus
doffy
a web auto run lib base on chrome headless
Stars: ✭ 13 (-38.1%)
Mutual labels:  casper
bloqly
Bloqly: JavaScript Smart Contracts Engine + SQL database
Stars: ✭ 29 (+38.1%)
Mutual labels:  consensus
ghost-theme-casperion
Casperion is a free Ghost theme. Casperion is based upon original Ghost theme Casper with some minor modifications and extensions.
Stars: ✭ 27 (+28.57%)
Mutual labels:  casper
detailed-plutus-lecture-notes
Initially started as my own personal lecture notes. Slowly, I'm converting this repo into an extremely detailed set of notes to help future pioneers, Cardano devs and anyone with an academic interest in DLTs and Blockchain Consensus Algorithms.
Stars: ✭ 21 (+0%)
Mutual labels:  consensus
scp
Standalone implementation of the Stellar Consensus Protocol.
Stars: ✭ 34 (+61.9%)
Mutual labels:  consensus
JSS-Resource-Tools
A CLI utility that utilises the Jamf Pro (previously Casper Suite) API in order to import, export and update JSS resources en-masse.
Stars: ✭ 24 (+14.29%)
Mutual labels:  casper
Raft-Paxos-Sample
MIT6.824实现分布式一致性算法——Raft&Paxos
Stars: ✭ 37 (+76.19%)
Mutual labels:  consensus
paxos-rs
Paxos implementation in Rust
Stars: ✭ 66 (+214.29%)
Mutual labels:  consensus
paxakos
Rust implementation of Paxos consensus algorithm
Stars: ✭ 79 (+276.19%)
Mutual labels:  consensus
little-raft
The lightest distributed consensus library. Run your own replicated state machine! ❤️
Stars: ✭ 316 (+1404.76%)
Mutual labels:  consensus
Motoro
Smart contracts for decentralized rentals of vehicles.
Stars: ✭ 96 (+357.14%)
Mutual labels:  consensus
BankBox
ColoredCoins desktop wallet application for digital currency issuance and management.
Stars: ✭ 60 (+185.71%)
Mutual labels:  consensus

Casper the Friendly Javascript Ghost 👻

Travis CI

A Javascript implementation of Vlad Zamfir's Casper the Friendly Ghost CBC consensus protocol.

The paper is based primarily from the CasperTFG paper by Vlad Zamfir and also draws inspiration from the current Python implementation by Nate Rush, Danny Ryan, Vlad Zamfir, Karl Floersch and others.

Note: this project is still in very early stages. It is likely faulty and is subject to significant change. This should only be the case for the next few weeks (i.e., until mid-April 2018).

Casper: GHOST or finality gadget?

There are two distinct projects, both sharing the name "Casper".

  1. Casper Correct-by-Construction (aka Casper CBC, "Vlad's Casper")
  2. Casper the Friendly Finality Gadget (aka Casper FFG, "Vitalik's Casper)

This project is implementing (1), Casper CBC. This project seeks to simulate a network of peers coming to consensus across a loosely-asynchronous network whilst tolerating some faulty behaviour. This project is not (at this stage) concerned with any economic incentive mechanisms (i.e., it does not implement staking).

For more detail, see Jon Choi's "Ethereum Casper 101" (the "A Tale of Two Caspers" section): https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0

Motivation

The motivation for creating a new implemenation can be seen in the following:

  • Browser compatibility: running Casper sims in the browser should hopefully improve accessibility for those who wish to understand how Casper TFG work.
  • Diversity: mutliple implementations will hopefully allow for a wider range of perspectives.

Requirements

This codebase has been developed in node v9.8.0. It uses some ES6 syntax and therefore some older versions of node will be incompatible.

Usage

For first time usage, clone the repo and run npm install in the repo directory.

Command-line

The command-line script is casper.js and it has a fully featured argument parser; you can run ./casper.js -h (or node casper.js -h) to view help.

Random Binary Conensus Simulator

Currenly the only available command-line function is $ ./casper.js random which will run a binary consensus simulation where the following conditions are randomised:

  • The initial estimate of the validators. I.e., if they choose to start with a 0 or 1.
  • The senders and recipients of messages for each round.

In this binary simulation, there is no concept of "rounds". I.e., validators will not wait for some minimum threshold of votes before they issue a new estimate to the network. This means that it is possible for all validators to reach consensus on a value which was not average of all validator starting points. E.g., there exists a pattern of messages so that validators with starting points (0, 1, 1) can come to consensus on the 0 value.

The random sim will output a JSON object to console with the following properties:

  • initialConfig: The starting values and weights for each validator. I.e., what their states were before the consensus process started.
  • decisions: The estimates and associated safety ratios for each validator, as of simulation completion.
  • majorityFlip: true if the majority of validators decided upon the average of all staring positions.
  • messageLogLength: the number of messages which were sent whilst forming consensus.

Example

The following example is running a simulation with the following attributes:

  • -n 3: Three validators will form consensus.
  • -s 0.5: The simulation will end once at least half (0.5) of validators consider themselves safe with half (0.5) the other validators. We do not wait for all validators to get to target safety because this can take a very long time with random message propagation.
$ ./casper.js random -n 3
{
  "intialConfig": [
    {
      "name": "0",
      "weight": 100,
      "startingPoint": 1
    },
    {
      "name": "1",
      "weight": 100,
      "startingPoint": 0
    },
    {
      "name": "2",
      "weight": 100,
      "startingPoint": 0
    }
  ],
  "decisions": {
    "0": {
      "estimate": 0,
      "safe": true,
      "safety": 1
    },
    "1": {
      "estimate": 0,
      "safe": true,
      "safety": 0.6666666666666666
    },
    "2": {
      "estimate": 0,
      "safe": true,
      "safety": 1
    }
  },
  "majorityFlip": false,
  "messageLogLength": 6
}

My laptop can comfortably run ./casper.js random -n 100 in about 5 seconds.

Tests

Tests are written in Mocha, run them with $ npm run test.

Notes

To reduce the processing burden of equivocation detection, some new requirements for message formation were added:

  • A validator must include a message from themself in the justifications of each message they send (unless the message is an "initial message" which does not provide any justification).
  • A validator must not include two messages from the same validator in their justification. This only applies to the first level of justifications, not the justifications of justifications (and their justifications, and so on).

Any validator which defies these rules will be flagged as Byzantine.

Roadmap

  • Binary Consensus
    • Estimator
    • Byzantine Fault Detection
    • Safety Oracle
    • Command-line simulator
    • Shared database for faster sims
  • Blockchain Consensus
  • Full code coverage for tests
  • Linting
  • Graphical simulation (to be implemented as a separate project)
Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].