Baseledger
Search…
Baseledger
Welcome (tl;dr)
Baseledger Introduction
Abstract
Baseledger Setups
The Baseline Protocol
Problems tackled
The Right Mainnet
Service Quality
Data Privacy
Integration
Lack of a Unified Architecture for Multi-Chain Coordination
Baseledger Concepts
Integration
Identity Management
Consensus Model
Data Privacy
Performance
Transaction Costs
Architecture of Architectures (Multi-Chain)
Example Use-Case
Energy Consumption & Sustainability
TrustMesh
Governance
Governance
Token Model (UBT)
Requirements
Token Model and UBT
Mainnet Howtos
The Baseledger Mainnet
How to become a validator
How to use the Mainnet
How to use the Baseledger Proxy
Testnet HowTos
The Baseledger Testnets
How to drop a Proof on Baseledger Lakewood
How to sync two Excel-Sheets with Baseledger
How to find information on UBT (Unibright Token)
Related Websites
Baseledger.net
Baseledger Mainnet Explorer
Unibright.io
Unibright Token (UBT)
Baseline Protocol
Appendix
Disclaimer & Imprint
Powered By GitBook
Consensus Model

Within the Baseledger implementation, we used and forked Tendermint . Tendermint BFT is a solution that packages the networking and consensus layers of a blockchain into a generic engine, allowing developers to focus on application development as opposed to the complex underlying protocol. Tendermint Core is a blockchain application platform; it provides the equivalent of a web-server, database, and supporting libraries for blockchain applications written in any programming language. Like a web-server serving web applications, Tendermint serves blockchain applications. More formally, Tendermint Core performs Byzantine Fault Tolerant (BFT) State Machine Replication (SMR) for arbitrary deterministic, finite state machines.
The Tendermint BFT engine is connected to the application by a socket protocol called the Application Blockchain Interface (ABCI). This protocol can be wrapped in any programming language, making it possible for developers to choose a language that fits their needs.
Many novel blockchains rely on BFT, including Cosmos.Network on Tendermint, and Libra on LibraBFT (built upon HotStuff). The Tendermint open-source project was born in 2014 to address the speed, scalability, and environmental issues of Bitcoin’s proof-of-work consensus algorithm by using and improving upon proven BFT algorithms developed at MIT in 1988 .
Tendermint is a partially synchronous BFT consensus protocol derived from the “DLS consensus algorithm” . Tendermint is notable for its simplicity, performance, and fork-accountability. The protocol requires a fixed known set of validators, where each validator is identified by their public key. Validators attempt to come to consensus on one block at a time, where a block is a list of transactions. Voting for consensus on a block proceeds in rounds. Each round has a round-leader, or proposer, who proposes a block. The validators then vote, in stages, on whether to accept the proposed block or move on to the next round. The proposer for a round is chosen deterministically from the ordered list of validators, in proportion to their voting power. The full details of the protocol are described in the Tendermint Github . Tendermint’s security derives from its use of optimal Byzantine fault-tolerance via super-majority (>⅔) voting and a locking mechanism. Together, they ensure that:
  • ≥⅓ voting power must be Byzantine to cause a violation of safety, where more than two values are committed.
  • If any set of validators ever succeeds in violating safety, or even attempts to do so, they can be identified by the protocol. This includes both voting for conflicting blocks and broadcasting unjustified votes.
In classical Byzantine fault-tolerant (BFT) algorithms, each node has the same weight. In Tendermint, nodes have a non-negative amount of voting power, and nodes that have positive voting power are called validators. Validators participate in the consensus protocol by broadcasting cryptographic signatures, or votes, to agree upon the next block.

Baseledger can have a block time up to the order of 1 second and handle up to thousands of transactions per second. In benchmarks of 64 nodes distributed across 7 data centers on 5 continents, on commodity cloud instances, the consensus implementation used can process thousands of transactions per second, with commit latencies on the order of one to two seconds. Notably, performance of well over a thousand transactions per second is maintained even in harsh adversarial conditions, with validators crashing or broadcasting maliciously crafted votes. See the figure below for details:
A property of the consensus algorithm is instant finality. This means that forks are never created as long as more than a third of the validators are honest (Byzantine). Users can be sure their transactions are finalized as soon as a block is created (which is not the case in Proof-of-Work blockchains like Bitcoin and Ethereum).
The consensus is not only fault tolerant, it is also accountable. Should the blockchain fork, there is a way to determine liability.
Baseledger Concepts - Previous
Identity Management
Next - Baseledger Concepts
Data Privacy
Last modified 1yr ago
Copy link
On this page