Thirdstage's Wiki
40 Pages
Add new page

On Blockchain

View source
Comments Share

General

Consensus Algorithm

Style Description Remarks
PoW Deters denial of service attacks and other service abuses such as spam on a network by requiring some work from the service requester, usually meaning processing time by a computer.
PoS
DPoS
PoS

PoW

BFT (Byzantine Fault Tolerance)

pBFT

ZKP

misc

  • Paxos : a family of protocols for solving consensus in a network of unreliable processors
Fault Type Cryptography Replica Requirement
Non Byzantine Failures Non Cryptographic 2F + 1
Non-malicious Byzantine Failures Non Cryptographic 2F + 1
Malicious Byzantine Failures Non Cryptographic 3F + 1
Malicious Byzantine Failures Cryptographic 2F + 1

Blockchian Networks

Network Symbol Consensus Style Description Remarks
BitCoin BTC PoW
Ethereum ETH PoW
EOS EOS DPoS

Smart Contract

Blockchain Language Remark
Ethereum Solidity
EOSIO C++

Key and Wallet

  • Shamir's Secret Sharing
    • a form of secret sharing, where a secret is divided into parts, giving each participant its own unique part.

Financial Business

Misc

Bitcoin

Concepts

BIP

BIP Title Description Type Status Remarks Related
BIP 32 Hierarchical Deterministic Wallets describes hierarchical deterministic wallets (or "HD Wallets") Informational Final
BIP 39 Mnemonic code for generating deterministic keys describes the implementation of a mnemonic code or mnemonic sentence -- a group of easy to remember words -- for the generation of deterministic wallets. Standards Track Proposed
BIP 43 Purpose Field for Deterministic Wallets introduces a "Purpose Field" for use in deterministic wallets based on algorithm described in BIP-0032 Informational Draft m/purpose'/* BIP 32
BIP 44 Multi-Account Hierarchy for Deterministic Wallets defines a logical hierarchy for deterministic wallets based on an algorithm described in BIP-0032 Standards Track Proposed m/44'/*'/*'/*/* BIP 32, BIP 43

HD Wallet

Format Purpose Description Remarks
m/0'/* Default Account
m/44'/coin_type'/*'/*/* Multi-Account m/44'/0': BTC, m/44'/60': ETH, m/44'/61': ETC

BIP 32

private parent key → private child key : possible
public parent key → public child key : possible
private parent key → public child key : possible
public parent key → private child key : impossible
  • Each leaf node in the tree corresponds to an actual key, while the internal nodes correspond to the collections of keys that descend from them.
  • The chain codes of the leaf nodes are ignored, and only their embedded private or public key is relevant.
  • Knowing an extended private key allows reconstruction of all descendant private keys and public keys.
  • Knowing an extended public keys allows reconstruction of all descendant non-hardened public keys.
256 bit entropy
private key
public key
extended private key
extended public key
private child key derivation(CKD) function
public child key derivation(CKD) function
computes extended public key
private key node m : master extended private key
public key node M : master extended public key
Serialization Format
Position Value Remarks
4 bytes version bytes
  • mainnet/public: 0x0488B21E
  • mainnet/private: 0x0488ADE4
  • testnet/public: 0x043587CF
  • testnet/private: 0x04358394
1 bytes depth
  • master node: 0x00
  • level-1 derived: 0x01
4 bytes the fingerprint of the parent's key master key: 0x00000000
4 bytes child number
32 bytes chain code 256 bit
33 bytes the public key or private key data

Ethereum

Substrate

Ripple

References

rippled API

Category API Methods Description Remarks
Public subscribe WebSocket requests periodic notifications from the server when certain events happen Ledger Stream, Validations Stream, Transaction Streams, Peer Status Stream, Order Book Streams
Admin ledger_request WebSocket, Commandline tells server to fetch a specific ledger version from its connected peers

Consensus

   Round Start --------------- Close -------------------- Consensus -------------------- Round End
                 Open phase            Establish phase                  Accept phase
  • The XRP Ledger Consensus Process
  • Consensus
    • Concensus
      • Through the consensus process, validating nodes agree on a specific subset of the candidate transactions to be considered for the next ledger
      • Consensus is an iterative process in which nodes relay proposals, or sets of candidate transactions.
      • Nodes communicate and update proposals until a supermajority 5 of peers agree on the same set of candidate transactions.
    • Validation
      • The validating nodes calculate a new version of the ledger and relay their results to the network, each sending a signed hash of the ledger it calculated based on the candidate transactions proposed during consensus.
      • In cases where a node is in the minority, having computed a ledger that differs from its peers, the node disregards the ledger it computed 9. It recomputes the correct ledger, or retrieves the correct ledger as needed.
  • rippled Server States
                                                            +--> full
                                                            |
   disconnected ---> connected ---> syncing ---> tracking --| 
                                                            |
                                                            +--> validating <-----> proposing

Transaction

  • Reliable Transaction Submission
    • Best Practices
    • Your rippled server should automatically acquire the missing ledger versions when it has spare resources (CPU/RAM/disk IO) to do so, unless the ledgers are older than its configured amount of history to store. Depending on the size of the gap and the resource usage of your server, acquiring missing ledgers should take a few minutes. You can also manually request your server to acquire historical ledger versions using the ledger_request method.
    • Use the LastLedgerSequence parameter to prevent undesirable cases where a transaction is not confirmed promptly but could be included in a future ledger. You should specify the LastLedgerSequence parameter on every transaction. Automated processes should use a value of 4 greater than the last validated ledger index to make sure that a transaction is validated or rejected in a predictable and prompt way.

Ledger

  • Ledgers
    • Ledger = Header + Transaction Tree + State Tree (Ledger Objects)
    • At any given time, a rippled instance has an in-progress "current" open ledger, plus some number of closed ledgers that have not yet been approved by consensus, and any number of historical ledgers that have been validated by consensus.
    • Only the validated ledgers are certain to be correct and immutable.
  • Ledger Header
    • Two ledgers with the same hash are always the same.
    • For validated ledgers, hash values and sequence numbers are equally valid and correlate 1:1.
    • Two different rippled servers may have different contents for a current ledger with the same ledger index, due to latency in propagating transactions throughout the network.
    • There may be multiple closed ledger versions competing to be validated by consensus. These ledger versions have the same sequence number but different contents (and different hashes). Only one of these closed ledgers can become validated.
    • A current ledger's contents change over time, which would cause its hash to change, even though its ledger index number stays the same. The hash of a ledger is not calculated until the ledger is closed.

Amendments

Readings

Troubleshooting

Sources

Component Type Description Remarks
SHAMapStoreImp.h, SHAMapStoreImp.cpp class
Setup struct deleteInterval, advisoryDelete, ledgerHistory, databasePath, deleteBatch, backOff, ageThreshold
Config.h class

Stellar

Hyperledger

Hyperledger Fabric

Readings

  • Concepts
    • Channels
      • Channel = Organizations + Ordering Service + Anchor Peers + Chaincodes + Ledger
      • At least one anchor peer per organization

Examples

Demos

Sources

  • fabric/core/ledger/ledgerconfig/ledger_config.go

Issues

Docker Images

fabric-peer

Config which is printed by "docker inspect --format='{{json .Config}}' ..." is 

   
 "Config": {
   "Hostname": "e7eddde82bec",
   "Domainname": "",
   "User": "",
   "AttachStdin": false,
   "AttachStdout": false,
   "AttachStderr": false,
   "Tty": false,
   "OpenStdin": false,
   "StdinOnce": false,
   "Env": [
     "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
     "PEER_CFG_PATH=/etc/hyperledger/fabric",
     "CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp/sampleconfig"
   ],
   "Cmd": [
     "peer",
     "node",
     "start"
   ],
   "ArgsEscaped": true,
   "Image": "sha256:793719e9dd193f580f32c5984ac47a8c0f986819e4795c039703b26bb6ad15ce",
   "Volumes": null,
   "WorkingDir": "",
   "Entrypoint": null,
   "OnBuild": [],
   "Labels": {
     "org.hyperledger.fabric.base.version": "0.3.0",
     "org.hyperledger.fabric.version": "1.0.0-alpha"
   }
 },

Fabric CA

Fabric SDK for Node.js

Performance Tuning

  • LVM (Logical Volume Manager)

Companions

PTE

R3 Corda

Concepts

Concept Description Remarks
State Object a digital document which records the existence, content and current state of an agreement between two or more parties
Ledger a set of immutable state objects
Consensus pure function whose responsibility is either to accept or reject a proposed transaction and which can be composed from simpler, reusable functions
Transaction Consume existing state objects and produce new state objects Transaction Validity, Transaction Uniqueness
Smart Contract
Uniqueness and Timestamping Services
Flow Framework 
          State Object ----+----> Contract Code
                           +----> Legal Prose

Features

References

  • End-State Principles
Principle Description Remarks
Inclusion Parties are able to discover each other freely, and transact directly, in a single, open network
Assured identity Parties will have assurance over the identity of participants in the network
Privacy The only parties who have access to the details of a transaction are those who participate in the transaction and those who need to assure themselves of transaction provenance.
Shared logic The behavior of agreements managed by the system will be described in computer code that is shared to ensure onsistency and validity of agreements
Legal footing Deals recorded by the ledger are, by contract, accepted as admissible evidence and legally binding by all parties in any dispute
Authoritative Facts recorded by the ledger are regarded as authoritative rather than “shadows” of authoritative data held elsewhere
Immutability Facts recorded on the ledger are final and immutable; errors and unwinds must be processed through a subsequent transaction
Open The system is open: open source, participation, development, governance and standards to ensure the platform balances the needs of its diverse user-base in a transparent fashion

Readings

Terra

Eris

References

Readings

Tendermint Core

Readings

IPFS

  • https://ipfs.io/
  • Desc. : A peer-to-peer hypermedia protocol to make the web faster, safer, and more open

NFT

  • Players/Contracts
Player Description Contract Source Contract Address Documentation Remarks
CryptoPunks 10,000 unique collectible characters with proof of ownership stored on the Ethereum blockchain. CryptoPunksMarket.sol CryptoPunksMarket
Rarible MintableToken (May-27-2020)
SuperRare Collect SuperRare Digital Artworks SuperRareV2 (Sep-05-2019)
Nifty Gateway the premier marketplace for Nifties, which are digital items you can truly own.
Decentraland a decentralized virtual reality platform powered by the Ethereum blockchain. Land Contracts


Marketplace Contracts
Collection Contracts

 LANDProxy


LANDRegistry
EstateProxy
EstateRegistry
MarketplaceProxy
Marketplace
MANAToken

Decentraland documentation
The Sandbox
Axie Infinity
Gods Unchained

Decentraland

The finite, traversable, 3D virtual space within Decentraland is called LAND, a non-fungible digital asset maintained in an Ethereum smart contract. Land is divided into parcels that are identified by cartesian coordinates (x,y). These parcels are permanently owned by members of the community and are purchased using MANA, Decentraland’s cryptocurrency token. This gives users full control over the environments and applications that they create, which can range from anything like static 3D scenes to more interactive applications or games.

Some parcels are further organized into themed communities, or Districts. By organizing parcels into Districts, the community can create shared spaces with common interests and uses. You can find a list of the original District Proposals on GitHub. The content that makes up Decentraland is stored and distributed via a decentralized network while ownership and transactions are validated on the Ethereum blockchain.

Decentraland is partnering with Matic to create a sidechain (a special kind of blockchain) that will be able to handle transactions faster and cheaper than the main Ethereum network. This sidechain will be ideal for in-game transactions, as changes can occur closer to real time and at a very low cost. For transactions that involve valuable items, we’ll still recommend the main Ethereum chain, as it will be more secure.

Cryptovoxels

Tool Description Remarks
Cryptovoxel Generator Chrome app to help easily manage your land parcels.
Cryptovoxels land sales map Highlights all parcels for sale, plotted on the map.
MagicaVoxel A free lightweight GPU-based voxel art editor and interactive path tracing renderer.
Babylon.js a powerful, beautiful, simple, and open game and rendering engine packed into a friendly JavaScript framework.
  • Smart Contracts
Contract Description Source Address Remarks
Parcel Parcel.sol 0x79986af15539de2db9a5086382daeda917a9cf0c(Jun-05-2018)
Wearables 0xa58b5224e2fd94020cb2837231b2b0e4247301a6(Oct-29-2019)

STO

AML

Polymath

CoFi OS

  • https://github.com/ConsenSys/ERC1400
  • Desc. : an advanced institutional technology platform for issuing and exchanging tokenized financial assets, powered by the Ethereum blockchain.

De-Fi

  • DeFi Pulse : a site where you can find the latest analytics and rankings of DeFi protocols.

MakerDAO

DAI

  • DAI
    • Decentralized Stable Coin
    • Backed by Ether

Compound

Synthetix

Mirror Protocol

Synthetic tokens are tokens that provide "synthetic" exposure to the physical or abstract good that they represent without requiring one-to-one backing.

Synthetic tokens tend to be more affordable to hold as they typically charge no holding fee.

Mirror is a protocol that allows anyone to issue and trade synthetic assets that track the price of real world assets.

Anyone can mint an mAsset by locking up collateral, either in the form of as stablecoin or a different mAsset.

The Mirror protocol creates incentives for minters to mint assets and provide liquidity for traders.

The Mirror protocol utilizes AMMs to facilitate mAsset, trading against stablecoins.

When the collateral ratio drops below the minimum, the Mirror protocol needs a way to retrieve and burn the respective mAssets. It does so by seizing a portion of the collateral and initiating an auction at a discount for anyone willing to sell the mAsset in exchange.

Resource/Tool Description Remarks
Mirror Whitepaper
Mirror Documentation
Mirror Smart Contract implementing Mirror Protocol on the Terra blockchain Mint, Factory, Gov
Mirror.js a client SDK for building applications that can interact with Mirror Protocol from within JavaScript runtimes
mirrorcli Command-line interface for Mirror Protocol on Terra
Mirror API an GraphQL-based data service that allows anybody to query data regarding the current and aggregate application state of the Mirror Protocol

Anchor Protocol

The Anchor rate is powered by a diversified stream of staking rewards from major proof-of-stake blockchains, and therefore can be expected to be much more stable than money market interest rates.

The Anchor protocol defines a money market between a lender, looking to earn stable yields on their stablecoins, and a borrower, looking to borrow stablecoins on stakeable assets.

Resource/Tool Description Remarks
Anchor Documentation
Anchor Money Market Contracts implementing Anchor Protocol on the Terra blockchain. Rust
Anchor Bonded Asset Contracts implementing bAsset(Bonded Asset) Protocol on the Terra blockchain.
Anchor.js a client SDK for building applications that can interact with Anchor Protocol from within JavaScript runtimes

DID

Concept Description Remarks
Holder A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. students, employees, customers
Issuer A role an entity performs by asserting claims about one or more subjects, creating a verifiable credential from these claims, and transmitting the verifiable credential to a holder. corporations, trade associations, governments
Verifier A role an entity performs by receiving one or more verifiable credentials, optionally inside a verifiable presentation, for processing.
Subject An entity about which claims are made. In many cases the holder of a verifiable credential is the subject, but in certain cases it is not. human beings, animals, things
Claim An assertion made about a subject.
Credential A set of one or more claims made by an issuer.
Verifiable Credential a tamper-evident credential that has authorship that can be cryptographically verified.

Metaverse

Retrieved from "https://3rdstage.fandom.com/wiki/On_Blockchain?oldid=17453"
Community content is available under CC-BY-SA unless otherwise noted.

Fan Feed

More 3rdstage's Wiki
Explore Wikis