This post is just what I ended up mashing into my keyboard while studying from various sources(references are at the end just read those for a deeper understanding) in order to understand how Cosmos SDK, tendermint and PoS blockchains work. A basic understanding of how blockchain and PoW(Proof of Work) works is needed to understand this post.
Personally I recommend watching this youtube video by 3brown1blue if you lack the above level of understanding.
- Open source framework for multi-asset public Proof-of-Stake(PoS) blockchains or PoA(Authority) like Cosmos Hub. Generally for application-specific BC(BlockChain)
- Point is interoperability with other BC
- Framework to build secure BC apps on top of Tendermint(pBFT system distributor?)
- Capabilities-based system, you can better reason about the security of interactions between modules
- Default consensus engine is Tendermint Core. Currently the most and only mature BFT consensus engine. Currently the gold standard for PoS systems
- Can be built using composable modules. Sort of like the NPM eco-system.
- Already used to build a lot of stuff. Thus proved with a market.
- In essence, BC is a replicated deterministic state machine.
- Deterministic -> A given state will end in the same final state if replayed the same sequence of transactions.
- Tendermint handles the replications, devs just have to define the state machine.(responsible for propagation and ordering transaction bytes)
- Tendermint needs Validators, validators are responsible for adding blocks of transactions to blockchain. The next validator is chosen by the consensus algorithm to be the next validator. Block is valid if more than 2/3 of the validators signed a prevote and precommit to it. + all transactions must be valid.
- BFT(Byzantine Fault Tolerant)-> basically a system that can still work even if some nodes or a part of a system malfunctions or decides to act maliciously
- TenderMint -> middleware that takes a state transition machine and replicates it on many machines.(Sharing the slate?)
- State machine is connected to underlying consensus engine using ABCI(Like a rest API?, gives methods that have Requests and Responses), which can be built using any language, thus flexible.
- ABCI allows devs to swap the consensus engine of app-specific BC. Only Tendermint is production-ready.
- Devs can tweak framework or consensus engine if they feel the need.
- Devs can explore the full spectrum of tradeoffs + design choices
- Automatic execution of code is possible.(Logic triggered on the beginning and end of each block.
- Performance, security is better.
- Sovereignty -> one of the major benefits. Stakeholders of the application have full control over the entire chain. Community will not be stuck if a bug is discovered. Has freedom to choose how it will evolve.(Unlike PoW BCs)
- Radically different development paradigm -> customized blockchain to work on a single application, devs can make design decisions required for application optimization. Increase in sovereignty, security, performance
- Software that is designed as an automated self-enforcing contract, it triggers a certain action after predetermined conditions are met.
- Concisely, lines of code that execute a specific function once certain conditions are met.(if… then… statements)
Drawbacks of smart contracts
- Lack flexibility, certain features are simply not implementable(Like automatic code execution)
- Built on the same virtual machine, thus restrain performance. When virtual machines are removed, benchmarks show 10x performance.
- Limitation in sovereignty.Ultimately superseded by the governance of the underlying blockchain. Bugs will screw your life :)
Gas and Fees
- gas -> how much computational resources a Tx(transaction) consumes.
- gas prices -> How much a user is willing to pay for a unit of gas.
- fees -> how much in fees the user is willing to pay in total.
- Ultimate value of the fees paid = ceil(gas * gasPrices)
- Validators decide whether or not to include a transaction in their block by comparing the given or calculated gas-prices to their local min-gas-prices. Tx will be rejected if gas-prices is not high enough. So users are incentivized to pay more.
- Every full-node that receives a Tx sends ABCI message CheckTx to app layer to check for validity and receives a response. If it passes checks, it is held in the node’s mempool(Pretty much a list of transactions unique to each node).
- Waiting area for all pending transactions. Waits to be included in a block. Higher fees make a transaction processed faster
- Practical Byzantine Fault Tolerance
- Aims on working even when there are malicious nodes operational. Only works if the maximum number of malicious nodes are not greater or equal to one-third of all nodes in the system.
- Client sends request to primary node -> primary broadcasts request to all secondary nodes -> primary + secondary nodes perform the service and send reply to client -> request is served successfully when client receives ‘m+1’ replies from different nodes in the network with the same result. ‘m’ is number of maximum faulty nodes.(Request, pre-prepare, prepare, commit, reply)
- Only works when number of nodes in the distributed network is small due to communication overhead(increases exponentially with every extra node)
- Susceptible to Sybil attacks(one party controls many nodes)
- Tendermint uses pBFT + DPoS(Delegated PoS)
- Application Blockchain Interface(Interface like REST but communicates between application and Tendermint)
- https://www.mintscan.io/ (Disclaimer - I am affiliated to cosmostation)
- Clicking through the site helps understand the above concepts to some extent(Not sure if it's the best site, any recommendations in the comments will be a great help)
Top comments (0)