Skip to content

Instantly share code, notes, and snippets.

@miguelmota

miguelmota/README.md

Last active December 29, 2022 23:27
Show Gist options
  • Save miguelmota/c083bc4037a201e8089f7abc9e458527 to your computer and use it in GitHub Desktop.
Save miguelmota/c083bc4037a201e8089f7abc9e458527 to your computer and use it in GitHub Desktop.
Download ZIP
summary notes on blockchain whitepaper reading
Raw
README.md

Blockchain reading notes

Rocket Pool

  • https://docs.rocketpool.net/guides/staking/overview.html#how-eth2-staking-works
  • deposit eth to rocket pool smart contracts
  • Smart Node Network run rocket pool Smart Node software.
  • Smart node communicates with protocol's smart contract and provide consensus required by Beacon Chain.
  • need 16 eth to run Smart Node
  • must put up RPL as collateral for insuring and bonding their node against bad behavior
  • Minipool Validators are smart contracts created by operators who deposit 16 ETH on their node. This smart contract recieves 16ETH deposits from users who want to stake but not run nodes (rETH stakers). A new validator is creatd when this contract contains a t total of 32 ETH (16 ETH initial and 16 ETH from rETH stakers)
  • RPL is Rocket Pool Protocol Token
    • rpl is governance token and can be staked on rocket pool node as insurance
  • 10% of 16 ETH must be staked in RPL when creating mini pool. This RPL is collateral and sold via auction to compensate protocol for missing ETH during slashing.
  • rETH is Rocket Pool Staking Deposit Token
    • rETH is tokenized staking deposit and the rwards it gains over time
    • rETH does not need to be locked and can be traded for ETH + rewards
  • Smart Nodes earn a percentage (comission) of all rewards from rETH user deposits. Higher comissions are earned when network is under high demand.
  • One withdrawals are enabled on ETH2 then you can come and go anytime
  • you can stake in multiples of 16 on same Smart Nod
  • and eth1 wallet is generated by Rocket Pool upon creating a new node, used to fund minipools
  • an eth2 validator requires 32 eth deposited and is reponsible for maintaining security of Beacon Chain.
  • eth2 validatorars attest protoposed blocks and submit new block proposals.
  • eth2 validators are assigned attestation and block proposals on a schedule.
  • missed attestions or block proposals result in slight penalty
  • if a validators is offline for x hours, it will make all of its lost eth back again in x hours of being online
  • attestations and block proposals are provided on the Beacon Chain
  • to the beacon chain, a minipool looks exactly like a solo validator
  • creation, withdrawaing, and rewards delegation is handled by rocket pool smart contracts on eth1 so it's completely decentralized
  • depositing ETH for rETh may be considered a taxable event depending on country.
  • rETH inherently accumulates value while the actual amount of token you hold remains constant so simply holding it does not generate any taxable events.
  • recommended to use Balancers metastable pool for swapping ETH for rETH for lower slippage and fees.
  • minimum ETH deposit is 0.1 ETH (for rETH)
  • minipool distributes your ETH (rETH) so all your stake is not with a single node
  • your ETH deposit (rETH) is distributed into different chunks
  • minipool moves 4 ETH chunks into smart nodes

bringing IBC to ethereum using zk-snarks https://ethresear.ch/t/bringing-ibc-to-ethereum-using-zk-snarks/13634

  • IBC works where the light clients of the origin and destination chains need to implement smart contracts to verify cross-chain transactions.
  • need to run tendermint light client on Ethereum as a solidity smart contract. ed25519 signature verification costs 500k, so cheaper alternative is to use zk proofs.
  • instead of verifying ed25519 signatures directrly on ethereum (ie 100 validator signatures), a zk-proof of signature validity proof is constructred and verified on-chain.
  • Electron Labs built a circom-based library that allows to generate a zk-snark proof for a batch of ed25519 signatures.

proto danksharding https://www.eip4844.com

  • EIP-4844
  • data for rollups
  • blobs are persistent in beacon nodes not execution engines
  • blobs are 4096 field-elements of 32 bytes each, max 16 per block (4096 * 32 * 16 = 2 MiB per block)
  • blobs are pruned after ~1 month, long enough to allow L2 actors to retrieve it

showkarma.xyz

  • aggregates and curates dao contributor activity
  • helps contributors showcase their work

https://sourcecred.io/docs/beta/cred/

  • Cred is core idea of SourceCred
  • cred is score and earned by making contributions to project
  • participants are rewards with digital currency "Grain" based on their cred
  • cred is community-specific and non-transferrable and retroactive

Saddle finance

https://gmx.io/

  • docs https://gmxio.gitbook.io/gmx/trading
  • perpetuals exchange with up to 30x leverage
  • current price: (mark price) chainlink oracle price
  • entry price: value at time of entering
  • liquidation price: value when liquidation is triggered

https://www.pikaprotocol.com/

Chainflip

  • https://chainflip.io/whitepaper.pdf

  • "Native cross chain swaps"

  • Establishes network of bonded nodes which can view, send, and receive transactions from multiple blockchains

  • Transactions form chains formed into liquidity pools

  • Allows for any swap to occur between pools

  • Network fees paid in FLIP

  • Swapper is non-custodial

  • System of vaults, which trustlessly secure funds of users

  • Validators operate vaults

  • Validators stake and earn rewards

  • State chain is operated by validators, allowing for consensus on when to create transactions

  • Vaults require multiple signatures from validators

  • State chain is based on Polkadot Substrate framework

  • State chain is coordination mechanism

  • Quoters are interface between user and state chain

  • Quoters insert quotes into state chain

  • Validators are selected to participate in indivudual vaults and have write access to state chain

  • Validators must bid for a position in next validator selection

  • Each vault is constructed from a subset of validator superset

  • Vault rotation is when existing subset is replaced with new subset

  • Validators submit witness transactions whenever enough confirmations are received on incoming transactions to vault

  • Witness transactions are signed by other validators and included in state chain

  • ChainBridge

  • https://chainbridge.chainsafe.io/

  • multiple relayers between blockchains so there's no single point of failure and can be multsig

  • each relayer has 3 components

    • connection: allow to connect to chains
    • listener: listen for messages on one chain
    • writer: write messages to another chain

  • contract emits events to relayer

  • termonilogy: origin chain, destination chain, deposit event,

  • token transfer: lock on origin, mint on destination

  • most contracts on origin chain don't allow for burning

  • smart contract components are set up by an admin

  • a dao can be used as admin

  • admin controls bridge contracts

  • relayer listens for deposit event

  • the message goes to relayer router

  • the relayer votes and creates or executes proposal (signs proposal)

  • message from finalized proposal is routed to receiving chain writer

  • chain writer sends transaction to destination chain

  • evm support

  • substrate pallet: a bridge pallet that can interact with parachains

  • need generic handle specific to your dapp contract in order to add dapp to bridge

  • relayers must be trusted to behave honestly

  • a transfer takes 2 - 5 minutes

  • in future, it will be a trustless relayer set. network security will be multi-layered with trustless relayer design.

  • Centrigue project uses chainbridge to bridge arbitrary messages and NFT tokens

  • AVA project is most popular bridge using chainbridge q and a

  • how does chainbridge differ from cosmos or chainlink cross-chain interopoabliy protocol (ccip) examples of generic arbitrary messages

  • bonder is trusting rollup sequencer (we dont run own verifier)

  • bonder risk: smart contract risk, reorg, rollup imploding

Element Finance https://www.element.fi/

  • receive 2 tokens
    • principal token
      • principle is locked up for specified time
      • can be redeemed after maturity period
      • can be traded for a discount in AMM
    • yield token
      • represents future yield of principle
      • yield increase as maturity increase Example:
    • for saving:
      • deposit 10 ETH
      • receive 10.03245 principle tokens
      • 1 ETH principle token = 0.09968 ETH
      • principle can be redeemed after 3 months
      • 2.71% APY
      • Earned at maturity is 0.03245 ETH 0.32%
      • can LP both principle tokens and yield tokens for additional yield

https://app.alchemix.fi/

  • instead of waiting for yield, you can get yield up front as loan
  • deposit 1000 DAI
  • get 500 alUSD
  • you can pool alUSD or convert 500 alUSD to 500 USDC
  • loan gets paid back from yield on yearn vaults

LayerZero https://layerzero.network/

  • "Trustless Omnichain Interoperability Protocol"
  • Bridges like ThorChain, AnySwap, etc are DEXes and require an intermediary token (RUNE, ANY, etc) to be minted and burned, and swapped for desired token at destination, requiring another transaction
  • With LayerZero, chain A can notify application on Chain B to grant user a token, using a single transaction without intermediary tokens. The exchange is handled by contracts on both sides, with LayerZero deliverying messages between the two
  • Valid Delivery: -every message m sent over the network is coupled with a transaction t on the sender chain.
    • A message m is delivered to the receiver if and only if the associated transaction t is valid and has been comitted on the sender chain
  • Centralized exchanges gurantee valid delivery
  • DEXes are not ideal because it requires converting sender token to intermediary token in one transaction, and then converting intermediary token to real token on destination in another transaction. Trust is also required in the intermediate consensus layer that confirmation transactions and mints token at the destination.
  • LayerZero Endpoints: user-facing interface to LayerZero. These are contracts implemented on each chain.
  • Uses Chainlink for Oracle to read block header from one chain and send it to another chain.
  • Relayer is an off-chain service like Oracle but instead it fetches the proof for a specified transaction.
  • The oracle and Relayer must be indepedent of each other, so then don't collude.
  • a message contains:
    • t: the unique transaction identifier for T
    • dst: a global identifier pointing to a smart contract on chain B
    • payload: any data that app A wishes to send to app B
    • relayer_args: arguments describing payments in formation in the event ap A wishes to use the reference Relayer.
  • validation will succeed if and only if the block header and transaction proof match
  • the evm library handles merkle-patricia tree validation for transactions on an evm block, using open-source implementation by Golden Gate

Chainflip

  • https://chainflip.io/whitepaper.pdf
  • "Native cross chain swaps"
  • Establishes network of bonded nodes which can view, send, and receive transactions from multiple blockchains
  • Transactions form chains formed into liquidity pools
  • Allows for any swap to occur between pools
  • Network fees paid in FLIP
  • Swapper is non-custodial
  • System of vaults, which trustlessly secure funds of users
  • Validators operate vaults
  • Validators stake and earn rewards
  • State chain is operated by validators, allowing for consensus on when to create transactions
  • Vaults require multiple signatures from validators
  • State chain is based on Polkadot Substrate framework
  • State chain is coordination mechanism
  • Quoters are interface between user and state chain
  • Quoters insert quotes into state chain
  • Validators are selected to participate in indivudual vaults and have write access to state chain
  • Validators must bid for a position in next validator selection
  • Each vault is constructed from a subset of validator superset
  • Vault rotation is when existing subset is replaced with new subset
  • Validators submit witness transactions whenever enough confirmations are received on incoming transactions to vault
  • Witness transactions are signed by other validators and included in state chain

LayerZero

  • Trustless inter-chain transactions
  • combines two indepedent entities:
    • an Oracle that provides the block header
    • a Relayer that provides proof associated with the aforementioned transaction
  • "valid delivery"
    • every message sent over the network is coupled with a transaction on the sender chain
    • a message is delivered to the received only if the associated transaction is valid and has been committed on the sender chain
  • "endpoints"
    • allow user to send a message
    • a LayerZero Endpoint is split into four modules:
      • Communicator, Validator, Network, Libraries
  • valid delivery can only happen if there's no collusion between Oracle and Relayer

Matic Network

  • https://docs.matic.network
  • provides hybrid proof-of-stake and plasma enabled sidechains
  • has generic validation layer
  • execution environment is seperate and can be plasma or EVM sidechain, and in future, optimism rollups and zkrollups
  • staking management contracts deployed on Layer 1
  • validators run Heimdall (proof-of-stake layer) or Bor (block producer layer) nodes
  • Heimdall is built on top of Cosmo's Terndermint fork called Peppermint and is responsible for block validation, block producer committee selection, checkpointing, and more
  • Heimdall layer handles aggregation of blocks produced by Bor into a merkle tree and periodically publishes root to root chain
  • Heimdall nodes validate blocks since last checkpoint
  • selected proposer of validator set is responsible for collecting all signatures and checkpointing
  • block producers are periodically shuffled via committee selection on Heimdall in durations called "spans"
  • Bor is responsible for aggregating transactions into blocks
  • Bor is a fork of geth
  • A "sprint" is a set of blocks within a span for which only a single block producer is chosen to produce blocks.
  • "wiggle" is the time that a producer should wait before starting to produce a block.
  • "Pulp" is RLP-based encoder
  • Bor has Matic token as native token
  • "State receiver" contract manages incoming state sync records. State sync mechanism allows to move state from Layer 1 to Bor.
  • Validators on Heimdall layer pickup the StateSynced event from a Sender contract and pass it on to the Bor layer
  • The data that was passed in the event is written on the Receiver contract
  • The Sender and Receiver contract are required to be mapped on Ethereum
  • StateSender.sol needs to be aware of each sender and receiver and requires manual registration
  • Sender contract is on L1, and Receiver contract is on L2
  • Checkpoints to root chain occure every 10-30min
  • the "Predicate" contract can only be trigged by the RootChainManager contract
  • the predicate ensures that only transactions that have been verified and checkpointed are executed on layer 1
  • when checkpoint is completed, the "exit" function on the rootchain manager which log event signature needs to be called using maticjs library
  • Root contract and child contract need to be paired
  • Once pair is set, it can't be changed. It's a one-to-one mapping.
  • If using proxy contracts, than pair contracts is mutable
  • Matic validators monitor a contract on layer 1 called "StateSender"
  • each time a registered contract on layer1 calls StateSender, an event is emitted that validators use to relay data to another contract on Matic chain.

https://compound.cash/

  • Compound chain
  • chain has validators executing same state
  • has "sidecar" functionality meaning it can execute things in off-chain workers
  • bridges connected peer chains
  • connector contracts on chains are called "Starport"
  • address on compound chain are identitfied by peer chain id (eg ethereum:0x123)
  • can send to any balance on compound chain to an other address on other chains
  • to borrow asset, sufficient collateral is needed
  • liquidations occur on first-come-first serve basis
  • CASH is the asset created by the protocol through borrowing
  • pay transaction fees in CASH
  • Byzantine Fault Tolerant proof-of-authority network
  • validated by governance-approved validators
  • requires 2/3 online nodes
  • validators earn reward from interest paid by CASH borrowers
  • governance token holders set initial validator set, supported assets, collateral factors, and CASH interest rates

loopring v3 (https://loopring.org) august 2020

  • https://github.com/Loopring/protocols/blob/master/packages/loopring_v3/DESIGN.md
  • dex protocol built with zkrollup
  • settle 2,000 trades per second
  • balances are tracked in merkle tree off-chain
  • data availablity for merkle tree can be turned on (rollup mode) or off (validium mode), when creating exchange built on loopring
  • off-chain token transfer takes minimal cost for generating proof for updating a merkle tree
  • the "operator" creates and commits blocks. A block contains a batch of deposits and ring settlements.
  • a block's state changes can be verified on-chain be generating a zk proof using a circuit.
  • user accounts and orders cannot be shared over different exchanges. exchanges can use same exchange contract so orders and user accounts are shared
  • the loopring contract is the creator of all exchanges built on top of loopring protocol
  • exchanges allowed to write own deposit contracts
  • must stake LRC to create exchange by calling forgeExchange on ProtocolRegistry contract
  • can withdraw stake when exchange is shutdown
  • only exchange owner can register tokens
  • exchange can set fees for account creation, account update, depositing, withdrawing
  • account is linked to msg.sender. users can update EdDSA public key used for signing off-chain requests.
  • ETH and ERC20 is suported for deposits.

zksync (wallet.zksync.io) august 2020

  • zkrollup
  • 3 confirmations to deposit into l2
  • about 150k gas to deposit
  • must approve token first to deposit
  • fees payable on the token transferred
  • withdraws to L1 under 15 minutes
  • finality in minutes
  • fist 500 users get MLTT (matter labs trial token souvenir)
  • plain text signature required before including tx in rollup block by server
  • users sign transactions and sbumit them to validators
  • validators rollup thousands of transactions in single block and submit root hash of new state to onchain contract, along with proof (a snark) that new state is result of txs applied to old state
  • state is published onchain as calldata to allow reconstructing state at every moment
  • proof and state delta is verified by contract
  • the snark verification is cheaper than every transaction individually
  • validators can never corrupt state or steal funds (unlike sidechains)
  • users can always retrieve funds from zkrollup even if validators stop cooperating because data is available (unlike plasma)
  • neither users or trusted third party need to be onlne to monitor zkrollup blocks in order prevent fraud (unlike fraud-proof systems such as payment channels or optimistic rollups)
  • proof time generation is expected to be 10-15 minutes
  • no privacy yet, no smart contract suppport yet. only secure transfers
  • in future, be able to write smart contract in Zync lang
  • if validity proof fails, just rety. no funds are lost, unlike optimistic rollups where if fraud proof fails then funds are lost
  • inspired by resilience of L1
  • works with contract-based accounts

fuel (fuel.sh) august 2020

  • based on utxos
  • does not require state serialization which means it does not need to compute the merkle root of the state after every transaction
  • has segregated witness
  • tx inputs include witness index
  • a single witness can be used for multiple tx inputs
  • txid is eip72 hash without witness
  • withdraw on fuel means burning tokens on rollups
  • block finalized can fully withdraw
  • 2 week finality (can no longer be proven invalid)
  • fast exit is 10 min: hash time lock with liqudity provider
  • allows output return data similar to OP_RETURN
  • tx can have max 8 inputs and max 8 outputs
  • txs -> batch -> root -> rollup block (consists of multiple roots) -> calldata -> onchain
  • onchain deposit -> event -> fuel node creates utxo

The Rainbow Network (2019)

  • https://rainbownet.work/RainbowNetwork.pdf
  • "The Rainbow Network: An Off-Chain Decentralized Synthetics Exchange"
  • rainbow channels - trade, lend, borrow, send, and receive any liquid asset off chain
  • don't need to have same type of asset that is collateralized to trade assets (unlike interledger and plasma cash)
  • example, USD as the underlying reference and ETH as the settlement currency
  • state channel closing logic can refer to a price oracle
  • the channel state is a contract-for-difference that cash-settles based on the prices of some reference assets

MultiChain https://www.multichain.com/blog/2018/06/scaling-blockchains-off-chain-data/

  • "A High-Efficiency Trustless Computing Network"

Moloch https://github.com/MolochVentures/Whitepaper/blob/master/Whitepaper.pdf

  • "Beating the Tragedy of the Commons using Decentralized Autonomous Organizations"
  • using a DAO structure to pool funds and vote on fund allocation; stakeholders share more effectively coordinate to share costs
  • immediate goal of Moloch DAO will be to fund development of ETH 2.0 by incentivizing coordination between various ETH 2.0 projects
  • lock funds in contract call the Guild Bank
  • contributes to the bank are given voting rights
  • member of the DAO are able to liquidate their votes to retrieve a proportional share of the funds from the guild
  • a rational investor would invest in a proposal that is likely to increase the value of the pool by more than the cost that is split amongst all members
  • members can quit the guild within a grace period after voting on a proposal completes but before those members ownership is affected by the proposal
  • only member who voted no can quit, forcing the yes votes to bear the cost of a malicious proposal
  • guild members need to be accepted by current members. Someone who rage quits is less likely to be admitted back in.

livepeer https://github.com/livepeer/wiki/blob/master/WHITEPAPER.md

  • provide alternative to centrazlized broadcasting solutions for any existing broadcaster
  • allow any node to send a live video into the network and pay to have it transcoded into various formats
  • allow any node to request the video from network
  • allow participants to contribute their processing power and bandwidth in service of transcoding and distribution of video
  • LPT is a staking token that participants who want to perform work on the network
  • ETH is used as fees paid from broadcasters
  • token is bonding mechanism is DPoS system. it's delegated towards transacoders or validators
  • Roles
    • Broadcaster - publishes original stream
    • Transcoder - transcode stream into another codec, bitrate, or packaging format
    • Relay Node - passes protocol messages and helps with distribution
    • Consumer - node requesting the stream
  • truebit for verification
  • PricePerSegment - lowest price willing to transcode segment of video
  • BlockRewardCut - the % of block reward that bonded nodes will pay them for the service transcoding (ex. 2%. if a bonded node were to receive 100LPT in block reward, then 2LPT to the transcoder)
  • FeeShare - the % of the fees from broadcasting jobs that the transcoder is willing to share with the bonded nodes who delegate towards it
  • f Sha3(N, BlockHash(N), Seg#) % VerificationRate == 0 then the segment # must be verified

transmute https://www.transmute.industries/whitepaper.pdf

  • "A rapid application development framework for centralized, decentralized and hybrid Ethereum applications and services"
  • delegated stake-based protocol
  • secure multiparty computation
  • integration of centralized and decentralized application components
  • pay-as-you-go network for applications
  • nodes are rewarded with fees paid by application developers and consumers as well as minted tokens (TST)
  • nodes compensated for providing access to minerals, by providing computation or storage
  • the platform uses kubernetes and OpenFaaS
  • transmute platform provides a simple interface for managing standalone services, reviewing analytics, and performing backups
  • packages are built with IPFS and Ethereum and the package manager is used to publish and manage decentralized applications and services
  • the package manager can be used to manage secrets which enables developers to easily implement integrations with third-parties
  • transmute protocol has two key responsibilities:
    • distribution, hosting, and execution of application code
    • economic incentives for game-theoretic security properties
  • protocol enables any node to create a mineral (unit of work) corresponding to storage or compute
  • enables any node to access a mineral from the network, corresponding to requests for computation or storage
  • enables any node to be compensated for providing access to minerals by providing computation or state
  • limit initial mineral types to computation provided by OpenFaaS and storage provided by IPFS
  • Roles
    • Producer: a user is a producer when they deploy minerals to the network
    • Consumer: a user is a consumer when they access a mineral on the network
    • Provider: a user is a provider when they support the access of a mineral by a consumer
    • Delegator: a user or node who bonds their token to a provider in order to receive a portion of the work reward
  • TNSC is transmute network smart contract
  • TST is fuel for creating minerals
  • TST is bonding mechanism in DPoS system where delegated towards providers and verifiers
  • TST is a unit of account corresponding to ability to interact with minerals representing compute and storage
  • protocol does not require consensus but defines rules for participation and the rewards and penalties for passing or failing role fulfillment
  • role of validators is played by providers
  • centralized verification oracle - trusting a public cloud oracle to verify work for testing and appropriate for certain private chain use cases
  • oraclize computation service - trusting a company who focuses on truthful verification to perform the operation
  • secure enclaves - leveraging services such as intel SGX that provides trusted computing environments which can be audited
  • slashing occurs when failing a verification, failing to invoke verification when required, not performing a proportional amount of work based on delegated stake

shiftnrg https://www.shiftnrg.org/download/shift-introductory-paper.pdf each dapp has own sidechain that's pegged to the mainchain the sidechains have their own rules and transaction uses dpos with 101 delegates, every 27 seconds hydra is a cms written in javascript meant for IPFS Jenga is a DNS that monitors all storage nodes to populate DNS records and unhealthy nodes are removed from cluster uses IPFS clusters for storage Fork of list it’s simply a cluster of ipfs nodes with a haproxy load balancer on top and dns monitor called Jenga that updates the load balancer users locked up tokens to store things and unlock when withdrawing storage

chain.link https://link.smartcontract.com/whitepaper "A Decentralized Oracle Network" chain link nodes return replies to data requests or queries made by a user contract three contracts which are reputation contract, order-matching contract, and an aggregating contract reputation contract keeps track of oracle-service-provider performance metrics the order-matching contract takes a proposed service level agreement, logs the SLA parameters, and collects bids from oracle providers the aggregating contract collects the oracle providers' responses and calculates the final collective result of the chainlink query. it also feeds provider metrics back into reputation contract ochain flow is oracle selection > data reporting > result aggregation SLA includes details such as query parameters and number of oracles needed by the purchaser purchaser submits SLA to an order-matching contract order-matching contract triggers a log that oracle providers monitor and filter based on their capabilities and service objectives when an oracle service provider binds on contract, they commit to it and attach the penalty amount that would lost due to misbehavior as defined in SLA once the SLA has received enough bids and the bidding window has ended then the requested number of oracles is selected from the pool of bids penalty payments that were offered during the bidding process are returned to oracles who were not selected finalized SLA is record and triggers a log notifying the selected oracles oracles reveal their results to the oracle contract and results will be fed to the aggregating contract aggregating contract tallies the collective results and calculates a weighted answer validity of each oracle response is reported to reputation contract chainlink nodes get assignments and each assignment has subtasks user-sc -> chainlink -> core -> adapter -> external api -> uturn reputation system based on total number of assigned requests, total number of completed requests, total number of accepted requests, average time to respond, amount of penalty payments LINK used to pay chanlink node operators TTP is trusted third party

OneLedger https://oneledger.io/whitepaper/oneledger-whitepaper.en.pdf "A Universal Blockchain Protocol Enabling Cross-ledger Access through Business Modularization" web of trust for identity decentralized pki provides SDK to allow porting of smart contracts to multiple platforms Channel consensus is reach with 2/3 votes

shipchain https://shipchain.io/shipchain-whitepaper.pdf unify shipment tracking across ethereum blockchain supplier -> manufacturer -> shipper -> retailer -> consumer sidechain for shipment transport information Web interface for managment

0chain

  • https://icorating.com/upload/whitepaper/0q4ooPuRjQ77NHioID2liwy2bkUt1n8sYoQa0U0b.pdf

  • "A Self-Forking, Zero-Cost, Sub-Second Blockchain Protocol"

  • miners generate and validate a block

  • sharders store the blocks

  • blobbers store unstructured

  • dual-chain blockchain protocol

  • stateless chain for iot, oracle, models

  • stateful chain for transactions, smart contracts, controllers

  • miners on each chain ignore transaction from their buffer queue that are not addressed to them

  • DPoS, miner produces block, validators verify

  • blobs are based on IPFS protocol

  • no reward for blob retrieval

  • blobber gets token rewards after n cycles

  • held accountable during retrieval process

  • 2/3rds majority to validate a transaction

  • secondary miners to verify transactions in case of network loss

  • inflation for rewards

  • Arbitrum

  • https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-kalodner.pdf

  • "Scalable. private smart contracts"

  • miners need only verify signatures to confirm that parties have agreed on a VM's behavior

  • can implement a smart contract as a VM that encodes tech rules of a contract

  • the creator of the vm designates a set of managers for the vm

  • parties interested in the vm's outcome can be a manager

  • if disagreement, both parties must submit proof of that single instruction where other verifiers can check this execution instruction

  • manager who was wrong pays penalty fee to the verifiers

  • verifiers have to do bookkeeping of track currency holdings, the hash of message inbox, and a single hashed state value for each vm

  • managers keep track of vm's computation and data

  • managers create signature if they agree

  • 'truebit' style dispute verification by using recursive bisection

  • entire state is a merkle tree

  • hashes of end state are what appear onchain

  • number and timing of execution steps are also stored onchain

  • messages and money transferred in stored onchain

  • onchain is only used for dispute resolution

  • unanimous assertions automatically are accepted by the verifier as the new state

  • disputable assertions are signed by only a single manager and that manager attaches a currency deposit to the assertion

  • a manager challenging assertion puts down deposit and both managers engage in bisection protocol

  • VM uses a stack-based architecture the inbox instruction gives the vm an inbox state the may be a linked list of multiple messages

  • arbitrum will use ethereum as the settlement layer

  • colony

  • https://colony.io/whitepaper.pdf

  • layer for human capital

  • colony is tool to coordinate effort to achieve a collective goal

  • tasks can be assigned to member of colony

  • colonies are divided into domains to ease management of tasks

  • completing task entitles member to claim a bounty assigned to task

  • bounties are erc-20

  • tokens are assigned to domains and tasks on a continious basis

  • funding flows are directed by members, prioritized by reputation

  • reputation is non-transferrable and decays over time to account for recent behaviour

  • dispute resolution system allows for any decision to be escalated to a vote of some or all members of colony

  • ballots weighted by member's reputation

  • ColonyNetwork smart contract is responsible for managing reputation mining process

  • Colony contract represents individual colonies, deployed by ColonyNetwork contract

  • CLNY are tokens in the first colony known as Meta Colony

  • tasks have a manager, worker, evaluator evaulator

  • reputation by colony

  • 1 point for unable to complete task

  • 2 points for completing task

  • 3 points for completing task to high standard

  • colony can bootstrap reputation points

  • every 600000 blocks a users' reputation in every domain decays by factor of 2

  • decay occurs every hour instead of every 3 months

  • reputation tree is a merkle tree of all individual reputation in a colony and the total reputation of each type held by the users in each colony

  • clny token holders are eligble to become miners

  • Haromony.one
  • https://harmony.one/tech
  • claim 10M tx/sec 100ms
  • uses Google QUIC
  • uses custom language called min
  • wasm compatible
  • integrates omniledger + rapidchain + chainspace for sharding consensus and contracts
  • uses formal verification
  • ArcBlock
  • https://www.arcblock.io/whitepaper/latest
  • Open Chain Access Protocol opens connectivity over multiple blockchain protocols
  • Blocklet is high-level application protocol, performs both on-chain and off-chain computing
  • blockchain 3.0 - cloud node, open chain access
  • build on top of aws
  • chain adapter built by community
  • blocklet is serverless computing architecture. used for smart contracts, oracle, resource, assets handling, off-chain business logic
  • blocklet communicates with blockchains through arcblock's open chain access protocol
  • orchestrated with Algorand-based consensus algorithm
  • ArcBlock Token (ART)
  • ArcBlock is building on top of AWS
  • They call their microservices "Blockets" which are trusted oracles that perform off-chain computation and can connect to chains via adapters
  • Adapters are created by the community
  • Have to pay token to use adapters
  • Marketplace where you can buy blocklets (serverless apps)
  • ArcBlock is not a blockchain
  • ArcBlock enables creation of blockchain enabled applications
  • ArcBlock is focusing on user experience hence not a blockchain with transactions
  • Uses pub/sub for broadcasting events
  • Open Chain Access Layer is a standard for interfaces with other chains
  • Token is ERC20
  • RChain
  • https://media.readthedocs.org/pdf/rchain-architecture/stable/rchain-architecture.pdf
  • proof-of-stake
  • turing complete
  • RhoVM
  • Rholang
  • Casper consensus
  • data separation using namespace addressing to reduce unnecessary data replication
  • data storage will be leased and will cost producers of that data in proportion to its size
  • charge for data to reduce attacks
  • vm is implementing a rate-limiting mechanism (for processing, memory, storage, bandwidth resources)
  • metering will not be not be at VM level and will be injected into the smart contract
  • rholang is built from rho-calculus.
  • rholang is concurrency oriented with focus on message-passing through channels
  • RhoVm is derived from computational model of the language similar to scala and haskell
  • decentralized cdn, SpecialK is on top of mongodb and rabbitmq
  • Stellar
  • horizon (rest api) is used to interact with stellar network
  • each stellar account hash public key and secret seed
  • each account must have at least 1 lumen
  • can send payments, change account, make offers to trade various kinds of currencies. these are called operations
  • a transaction is a group of operations
  • if any operation fails than the whole transaction fails
  • base fee is 100 stroops per operation ( 0.00001 XLM)
  • XDR is transaction data in binary format
  • anchors are entities the people trust to hold their deposits and issue credits into the stellar network for those deposits
  • anchors are bridge between existing currencies and stellar network
  • anchors are organizations like banks, savings institutions, etc..
  • issuing assets is the most basic activity of an anchor
  • federation allows a single stellar account to represent multiple people
  • an anchor maintains two accounts: an issuing account used for issuing and destroying assets, and a base account used to transact with other stellar accounts which holds a balance of assets issued by the issuing account
  • task of an anchor is handling regulatory compliance like AML and KYC
  • 1 stroop is one ten-millionth: 1/10000000 or 0.0000001 XLM
  • tenfold
  • http://files.binarymint.io/tenfold/lightpaper-v2.pdf
  • layer 2 solution
  • agnostic to the layer 1 chain
  • use deterministic state transition systems as basis for consensus
  • use ipfs for storage
  • tenfold stores minimal state in an registry
  • tenfold uses scuttlebutt for p2p
  • tenfold requires token holders to vote on state validity and run application off-chain to check for correctness
  • tenfold relies on token holders to act rational and vote (to maintain registry validity and token value
  • tenfold's g2m is ethereum
  • validators download state machine from ipfs to verify program
  • Polkadot
  • connect chain with distinct state machines and consensus
  • support public and private chains in same network
  • relay chain connects parachains. coordinates consensus and transaction delivery between chains
  • parachains are constituent blockchains which gather and process transactions
  • bridges link to blockchains with their own consensus
  • webassembly stored onchain in parachain registry
  • collator node creates candidate blocks that satisfy the validity function
  • message queues- candidates must also process incoming and produce outgoing messages
  • PoC-1 - governance, staking, basic UI, forkless upgrades
  • PoC-2 - 'co-finalization' of non-communicating parachains and basic light client
  • PoC-3 - implementation of hybrid consensus
  • PoC-4 - implementation of validity/availability game
  • validators secure relay chain by staking DOTs, validate collator proofs, participate in consensus with other validators (2/3)
  • nominators secure relay chain by selecting validators and staking dot
  • collators collect parachain transactions from users and producing transition proofs for validators. monitor network and prove bad behavior to validators
  • fisherman monitor network and prove bad behavior to validators
  • drop notion of a globally coherent state machine
  • validators help seal new blocks
  • each parachain has a group of validators
  • all validators must ratify the relay-chain block itself
  • ratifying essentially means moving data from a parachains output queue to another parachains input queue, processing the transactions of the ratified relay-chain transaction set and ratifying the final block
  • validator is punished for not fulling duty
  • availability guarantors are similar to fisherman and will be nudge validators when a validator is unavailable
  • to prevent overweight blocks sent to validators, the relay chain account sending it must have funds in their account, otherwise it'll be dropped immediately
  • validators must execute transactions in it
  • collators have incentive to ensure that all data is available for their chosen parachain
  • parachain collators are unbonded operators who are specific to a parachain
  • parachain collator must be fully synchronized with relay chain and parachain, and they collect the fees
  • transaction fees can be shared with parachain validators
  • polkadot is not responsible for spam processing (only prevention of spam transaction data)
  • new chains will have short removal period to allow for experimentation
  • collators and parachain collators are different groups
  • double-signing an result in loss of entire bond
  • bond is given to the informant and honest actors
  • nominator is stake-holding party who contributes to the security bond of a validator
  • collator maintains full-node for a particular parachain
  • create unsealed block and provide it, together with a zero-knowledge proof, to one or more validators responsible for proposing a parachain block
  • collators will work closely with validators
  • freelance collators will create a market offering valid parachain blocks in return for a share of the reward immediately
  • fisherman are bounty hunters motivated by one-off reward
  • fishername name comes from expected frequency of reward
  • 2/3 of validators must act benevolently for fisherman to get reward
  • fisherman must post a small bond to prevent sybil attack
  • collators broadcast blocks to fisherman and validators
  • global state will be address based and only for balances to prevent replays and a transaction counter, and for stake accounting
  • deployment of contracts cannot be done through transactions in relay chain
  • compute resource usage (gas) is not accounted in relay chain since public functions are fixed
  • staking contract maintains the validator set, and manages
    • which accounts are currently validators
    • which are available to become validators at short notice
    • which accounts have placed stake nominating to a validator
    • properties of each including staking volume, acceptable payout-rates, and addresses and short-term session identities
  • it allows an account to register a desire to become a bonded validator, or to nominate some identity, and to register desire to exit this status
  • parachain registry: a registry where each parachain is defined
  • 2/3 votes required to admit new parachain
  • removal of parachains come after a referendum which would require a substantial grace period to allow an orderly transition to either a standalone chain or to become part of some other consensus-system
  • availability guarantors are similar to fisherman and will be nudge validators when a validator is unavailable
  • to prevent overweight blocks sent to validators, the relay chain account sending it must have funds in their account, otherwise it'll be dropped immediately
  • validators must execute transactions in it
  • collators have incentive to ensure that all data is available for their chosen parachain
  • parachain collators are unbonded operators who are specific to a parachain
  • parachain collator must be fully synchronized with relay chain and parachain, and they collect the fees
  • transaction fees can be shared with parachain validators
  • polkadot is not responsible for spam processing (only prevention of spam transaction data)
  • new chains will have short removal period to allow for experimentation
  • collators and parachain collators are different groups
  • parachains are leased anywhere from 3 months to 5 years
  • bridging chain with absolute finality with chain with probabilistic finality. Is this case it's best to just wait for confirmations
  • you have to implement, version, authorities, and execute_block. authorities are who are allowed to mine blocks which depends o consensus
  • you have to bond tokens for a certain period of time to show that you are committed to the network and accept the rules before you can stake
  • slashing burns tokens to increase scarcity
  • each parachain will have a predetermined group of validator
  • all transactions from parachain blocks are referenced in relay chain blocks
  • STF - state transition function
  • substrate runtime storage is meant to store the state of the business logic on which the runtime operates. it is not used to store generated data the the UI needs. Strings are not supported in storage. use bytearray for general data or ipfs hash.
  • with substrate, state is not reverted back on failure like ethereum so you need to mak e sure there are no side effects
  • Validators are paid through inflation (regular PoS) and also by parachains paying in DOTs to message other parachains.
  • can support about 80 parachains
  • grace period when voted out
  • polkadot v2 end of 2020 before eth2.0
  • AIKON - The Open Rights Exchange (ORE)
  • https://aikon.com/ORE-whitepaper.html
  • wrap api to make it 'decentralized'
  • api marketplace for providers to sell and consumers to discover and buy and use them
  • ORE specifies API access control, validation and payment
  • ore network gives bearer token to consumer
  • bearer token to exchange for assets
  • api consumers hold their own access rights
  • pegged to ethereum
  • have their own nodes (ORE nodes)
  • have their own stable coin ('CPU' cloud processing unit)
  • CPU entitles holder to compute power
  • can sell api vouchers
  • api holder is written to ORE rights chain
  • review system for apis
  • sovrin
  • https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf
  • decentralized pki - store public key on chain
  • attestations on claims
  • verifiers verify signers signature
  • owner of data must countersign claim -based on the Hyperledger Indy Project
  • Evernym is the for profit arm
  • Evernym donated sovrin codebase to linux foundation
  • SSI: self-sovereign identity
  • verifiable claims use zk proofs to support data minimization
  • owners can share data with verifiers, verifier pays owner with token for data
  • Sovrin is built on top of hyperledger-indy
  • the Sovrin public permissioned chained is ran by the Sovrin Foundation
  • the Sovrin Foundation accepts anyone to participate as long as they adhere to the Sovrin Trust Framework (constitutional based model)
  • these validators are called Stewards
  • Orchid Protocol
  • https://www.orchid.com/whitepaper.pdf
  • organizes bandwidth sellers into a p2p network termed Orchid Market
  • customers connect to orchid market, and pay bandwidth sellers in order to form a proxy chain to a specific resource on the internet
  • no single relay or proxy holds both pieces of info
  • source or customer node - participant initiating a transaction
  • relay node - intermediary participants that forward network traffic
  • proxy or exit node - participant that connects to a requested global internet site
  • emphbandwidth seller - a relay or proxy
  • peers produce "Medallions" to demonstrate their "realness"
  • Medallions are a token for proof-of-work and license to participate in the network
  • Akash Network
  • https://docsend.com/view/fygzt3g
  • clients: those who need computing capacity
  • providers are computing capacity leasers
  • "supercloud"
  • clients post work and resource providers bid on them
  • workloads are docker containers
  • offer peer to peer protocol for distributing workloads
  • orderbook between users and data centers
  • a 'lease' is created when a match occurs. they are the binding agent
  • mTLS communication
  • resource providers must stake using their token (AKASH)
  • no minimum on how much resource providers can stake but will seen as more reputable
  • deployment is described in a manifest
  • hash of manifest is known as deployment version and stored onchain
  • new deployment is created if current deployment goes down (self-healing)
  • entirely new blockchain (called Photon) using tendermint consensus
  • Dispatch Labs
  • https://www.dispatchlabs.io/wp-content/uploads/2018/03/Technical-Whitepaper.pdf
  • Dispatch Ledger
  • Dispatch Artifact Network (DAN)
  • Dispatch Virtual Machine (DVM)
  • Delegated Asynchronous Proof-of-Stake
  • rate limiting as alternative to gas
  • zero tx fees
  • DAN is comprised of a distributed network of Farmers, storing Artifacts, or merkelized units of data
  • DVM supports EVM
  • 100,000 tx/s DAPoS
  • Dispatch Guru enables trustless analytical querying of data distributed across the DAN
  • data researchers can pay data owners to query their data for analytics, without requiring data to owner to reveal data
  • world state
    • account states
    • election states
  • account state
    • address
    • balance
    • bookkeeper: if true, can be elected as delegate
    • codehash: hash of DVM code
    • root: root node of a merkle patricia tree
    • name: human-readable username
  • election state
    • count: how many of the top voted delegates are considered officially elected
    • salary: how many divvitos each delegate's account is credited for their work
    • delegates: ordered list of the highest voted delegates
  • transaction types
    • 0: token transfer
    • 1: deploy
    • 2: execute
    • 3: election
  • Divvy is the currency
  • Divvito is smallest unit 10^8
  • bandwidth in hertz
  • artifacts are the distributed data objects stored in DAN
  • Uploaders see the DAN with artifacts
  • Downloaders are artifact consumers
  • Farmers store artifacts for Uploaders, distribute Artifacts to Downloaders, execute analytics against their artifact for the Guru
  • Farmers are compensated for their storage by Uploaders and bandwidth by the Downloaders
  • Delphi
  • https://docs.google.com/document/d/1CNBjz4oTUTQo2VjRh2jK0VBY5z7GAVPwT8YsVtOv1Ns/edit
  • “a Mechanism for Staking and Arbitration”
  • staker: people who stake tokens
  • challengers: people who submit claims
  • tcr is used to select adjudicators
  • entities registered in tcr are called arbiters who have staked
  • arbiters collect fees in exchange for their services
  • arbiters share a plurality opinion in adjudicating a claim
  • if arbiter rules in favor of the challenger, fee is returned to them along with their claim amount
  • if arbiters reject the claim, the challenger's deposit pays the arbitration fee for the claim
  • arbitration fees are split among the plurality voting bloc of arbiters in each claim
  • stake can be eth or erc20
  • Codius
  • https://github.com/codius/codius-wiki/wiki/White-Paper#code-sandboxing
  • oracles are trusted entities which sign claims about the state of the world
  • hosts are the same as the oracles
  • deterministic compilation of code
  • sandboxed code execution environment using Google's Native client
  • pods are hardware isolated vms
  • multiple containers can run inside of a pod
  • 8base
  • Developer focuses on ui and ux
  • Cloud-based apps
  • Like squarespace for blockchain
  • ‘Citizen developers’ - non dev people, business people
  • Can use graphql api
  • BaaS
  • Serverless
  • Blockchain agnostic

8gig https://docsend.com/view/96whmwe

  • Piece of 8 token on ethereum
  • working on plasma mvp implementation
  • tx paid in token
  • staking is required to engage with others
  • staking also called 'posting a bond'
  • must define project parameters first before posting gig
  • params:
  • software specification
  • price
  • delivery timeline
  • evaluation period
  • token price risk
  • stake to post gig
  • developer paid at each milestone
  • arbiters are validators with the highest reputation to handle disputes
  • developer must request validation
  • dev must stake minimum, validators can counter-bid
  • challenge period can be posted during validation
  • reputation system
  • Elastos
  • https://www.elastos.org/wp-content/uploads/2018/White%20Papers/elastos_whitepaper_en.pdf?_t=1526235330
  • "Smart-web powered by blockchain"
  • allow access to content without going through an intermediary
  • issue IDs for digital content
  • create a web where each device, individual, web site, and digital asset has a trustworthy ID
  • Elastos Runtime is a lightweight operating system that prevents apps and services from directly accessing the internet. This runs on a customer's mobile device or PC
  • Elastos Carrier is a peer-to-peer layer.
  • Elastos SDK is used for applications access IDs and elastos carrier services
  • bitcoin is parent blockchain of elastos
  • merged mining with bitcoin means a single node doesn't diminish the realiability of the ledger information
  • elastos token (ELA) i used for trading, investing in digital assets, paying for fees
  • 33 million ELA max
  • iExec
  • https://iex.ec/whitepaper/iExec-WPv3.0-English.pdf
  • "Blockchain-Based Decentralized Cloud Computing "
  • aims to provide manageable infrastructure sidechains
  • relies on Ethereum but also working on polkadot bridges
  • relies on XtremWeb-HEP, an open source desktop grid software which implements fault-tolerance, multi-applications, multi-users, hybrid public/private infrastructure, deployment of virtual images, data management, security and accountability
  • Proof-of-Contribution (PoCo) protocol for off-chain consensus
  • application must have a deterministic result to reach consensus
  • iexec doesn’t support indefinitely running processes like a server
  • front-end -> ethereum -> oracle -> scheduler -> workers
  • fog computing
  • marketplace where agents propose resources and where deals are made using RLC tokens
  • workers are people who own computing resources
  • worker pools organize workers contributions and get paid a fee but don’t do computation. They compete to attract workers.
  • worker pools are led by a scheduler who organizes the work distribution
  • dapp providers are those who deploy applications to the iexec platform
  • matchmaking algorithm determines if task can be ran on this machine based on compute requirements
  • Proof of concept applications include video transcoding, physics simulation, digital signal processing, audio analysis, optimization algorithms
  • option to pay-per-task
  • have a dapp store and developers can make monetize dapps they offer -community edition version (V1) -enterprise edition (V2, V3, V4) -research edition for addressing wider topics such as IOT and fog computing (V5) -ethereum smart contract api for task execution and reporting of completion with results
  • Blockstack
  • https://blockstack.org/whitepaper.pdf
  • “Blockstack: A New Internet for Decentralized Applications”
  • services for identity, discovery, and storage
  • virtualchains - used to bind digital property, like domain names, to public keys
  • new node on network can verify all data bindings
  • Atlas - a peer network, gives global index for discovery information
  • Gaia - decentralization storage system
  • ‘virtualchain’ is a layer 2 turing complete vm, like evm or wasm
  • using blockchain to authenticate the application’s code and data before the user runs it
  • blockchain nodes see raw transactions but the logic to process exists at the virtualchain level
  • blockstack store 'zone files' for peer discovery in the discovery layer
  • peer nodes maintain a full copy of all zone files (4kb per file)
  • Cartesi
  • https://cartesi.io/cartesi_whitepaper.pdf
  • layer-2 platform for the development and deployment of scalable decentralized applications
  • off-chain components run in Cartesi Nodes
  • Cartesi Nodes provide dapp developers with reproducible Cartesi Machines
  • Cartesi Nodes are developers to run native code
  • off-chain components run under a complete Linux os
  • reproducible computations run inside the cartesi machines
  • nodes interact with cartesi machines by defined host interface
  • RISC-V based on 32-bit integer instruction set
  • floating point number are emulated at the software layer

  • Hyperledger smart contracts

  • https://www.hyperledger.org/wp-content/uploads/2018/04/Hyperledger_Arch_WG_Paper_2_SmartContracts.pdf

  • installed smart contracts

    • install business logic on the validators in the network before the network is launched

  • on-chain smart contracts

    • deploy business logic as a transaction committed to the blockchain and then called by subsequent transactions. with on-chain smart contract

  • smart contract processing

    • smart contract inputs include contract identifier, transaction request, and current state of ledger
    • output includes new state and any side effects
    • smart contract interpreter packages the new state, an attestation of correctness, and any required ordering hints for the consensus layer
    • side effects can include event notifications, requests to other smart contracts, modifications to global resources, or even irreversible actions like releasing sensitive information or shipping a package

  • transactions

    • transactions are atomic (either not started or completed). a transaction cannot be partly completed, this ensures transactions integrity
    • implicit reference
      • impossible to determine the order of transactions, transactions are repeatedly tried to apply as their prerequisites are satisfied
    • explicit reference
      • the user submitting the transaction specifies the ordering with some form of transaction identifiers

  • smart contract integrity and availability

    • denial of service protection
    • sandboxing (containers)
    • resource management / flow control
      • can apply time or token-based resource management techniques to ensure that any particular contract does not consume excessive resources
    • application lifecycle management (ALM)
      • testing, deployment, updates, decommissioning

  • system chaincode

    • handles system-related transactions such as lifecycle management and policy configuration
    • application chaincode
      • manages application states on the ledger
      • application package includes metadata about chaincode including name, version, and counterparty signatures. chaincode package is installed on the network nodes of counterparties
      • member of network activates chaincode by submitting an instantiation transaction. if transaction is approved, the chain enter and active state where it can receive transactions from users
    • transaction can modify world state accordingly. chaincode can be upgrade via an upgrade transaction
  • Hyperledger consensus
  • https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_Paper_1_Consensus.pdf
  • consensus layer
    • responsible for generating an agreement on the order and confirming the correctness of set of transactions
  • smart contract layer
  • responsible for proposing transaction requests and determining if transactions are valid by executing business logic
  • communication layer
    • responsible for p2p message transport between nodes
  • data store abstraction
    • allows different data-stores to be used by other modules
  • crypto abstraction
    • allow different crypto algorithms or modules to be swapped
  • identity services
    • enrollment and registration of identities
  • policy services
    • responsible for policy management
  • APIs
    • enable clients to interact with blockchain
  • Interoperation
    • support interoperation between different blockchain instances
  • Kafka in hyperledger fabric
    • permissioned voting-voted. leader does ordering. in-sync replicas can be voted as leader
  • RBFT in hyperledger indy
    • permissioned voting based strategy. all instances do ordering but only the requests ordered by the master instance are actually executed. more nodes in network, more time it takes to reach consensus.
  • Sumeragi in Hyperledger Iroha
  • permissioned server reputation system. more nodes in network, more time it takes to reach consensus
  • PoET in hyperledger sawtooth
    • permissioned, lottery-based strategy. finality can be delayed due to forks that must be resolved
  • Consensus in hyperledger fabric
    • Endorsement
      • driven by policy (m out of n sigs)
    • Ordering
      • accepts endorsed transactions and agrees to the order to be committed to ledger
    • Validation
      • takes block of ordered transactions and validates the correctness of results broadcast(blob): a client calls this to broadcast an arbitrary message blob for dissemination over the channel. same as request(blob) in the BFT context
  • deliver(seqno, prevhash, blob): ordering service calls this on the peer to deliver the message blog. also called notify() in pub-sub or commit() in BFT systems
  • RBFT - Redundant Byzantine Fault Tolerance

  • Hyperledger intro

  • https://www.hyperledger.org/wp-content/uploads/2018/08/HL_Whitepaper_IntroductiontoHyperledger.pdf

  • Design philosophy

    • Modular
    • Highly secure
    • interoperable
    • cryptocurrency-agnostic
    • complete with APIs

  • Use cases

    • Banking - applying for a loan
    • Financial services - post-trade processing
    • Healthcare - credentialing physicians
    • IT - managing portable identities
    • Supply chain management - tracking from ocean to table

  • Post-trade processing includes

    • Trade validation - validating and confirming the transaction following the execution of the trade
    • Clearing - matching the trade instructions and confirmations across different counterparties as well as the potential netting activities

  • settlement - legally realizing the contractual obligations to reach the finality of the transaction

  • custody activities - adjusting the positions held with the custodians on behalf of the counterparties

  • reporting - satisfying all reporting requirements for regulatory and internal risk

  • Hyperledger Indy

  • manage identity, portable

  • w3c standards for verifiable claims

  • access control and policy

  • issuer signs claim, owner countersigns claim, verifier verifies signature

  • Decentralized Identifiers (DIDs)

  • Hyperledger Sawtooth

  • supply chain tracking

  • platform for deploying and running distributed ledgers

  • proof of elapsed time (PoET)

  • parallel transaction execution

  • Hyperledger Burrow

    • EVM interpreter

  • Hyperledger fabric

    • modular architecture
    • platform for building distributed ledger solutions

  • Hyperledger Quilt

  • connect separate chains

  • interoperability by implementing ILP

  • Hyperledger Caliper

    • measures performance of any blockchain by using a set of predefined use cases

  • Hyperledger Cello

    • tools to bring on-demand deployment model to the blockchain ecosystem

  • Hyperledger composer

    • toolset and framework for blockchain application development

  • Hyperledger explorer

    • dashboard for viewing information on the network including, blocks, node logs, statistics, smart contracts and transactions
  • ICON
  • https://docs.icon.foundation/ICON-Whitepaper-EN-Draft.pdf
  • allow independent blockchains to transact with one another
  • Community : network of different nodes with same governance system (ie bitcoin or ethereum)
  • C-Node (community node) : building block of a community that affects consensus or decision making
  • C-Rep (community representative) : right to vote on verification and governance transactions in ICON republic. Receive incentive. Duties are transferable
  • ICON Republic : connector of different communities. Comprised of C-Reps and other Citizen Nodes
  • Citizen Node : anyone can participate as a Citizen node by dapps created on loopchain. Does not have voting rights. Can only create transactions. Can be a C-Rep with if conditions are met
  • Communities connect via a DEX on the ICON Republic
  • Governance of ICON Republic is determined by the consensus process of C-Reps
  • Nexus : a loopchain-based blockchain. A multi-channel blockchain
  • ICX : ICON exchange token in Nexus
  • SCORE: the smart contract
  • dapps are registered in the dapp store
  • nodes must install dapp from store in order to submit tx
  • light clients confirm transactions
  • full nodes validate the transactions
  • IISS : ICON Incentive Scoring System
  • verification nodes transfers the transactions that need to be executed to the leader node
  • leaders creates a block and sends it to verifiers
  • verifiers confirm the creation of block, check the block level and data, broadcast to all nodes
  • leaders are rotated for every block creation
  • developers can update the contract by using a remote repository called SCORE store
  • Blink
  • https://blink.network/media/blink-protocol.pdf
  • "Proof-of-stake distributed consensus protocol"
  • Proof of stake
  • Each account has a chain of transactions applied to it
  • “Account supervisor” is the “locker” for the account
  • CTH chained transaction hash
  • lockers are selected proportional to their collateral
  • collateral used as insurance policy in case of misbehaves
  • DaoStack
  • https://daostack.io/wp/DAOstack-White-Paper-en.pdf
  • Decentralized Autonomous Organization (DAO)
  • self-organizing cooperation
  • "smart company" aka "smart agency"
  • smart agency is operated by smart contracts
  • reputation system
  • protocol based governance (yes/no majority)
  • vote weighted by reputation
  • free markets are "super scalable" structures
  • Hypernet
  • https://hypernetwork.io/HypernetWhitePaper_v1.1.pdf
  • “Distributed High-Performance Computing Powered by Blockchain Technology”
  • “Distributed Average Consensus” (DAC)
  • “Sellers” offer compute power
  • “Buyers” submit jobs to the network
  • Processes are replicated with other sellers
  • Sellers submit hashes of the results
  • Elrond
  • https://elrond.network/files/Elrond_Whitepaper_EN.pdf
  • Divides wallet address key space for sharding
  • Balances nodes for each shard
  • Auto tx route to shard
  • Secure proof of stake (SPoS)
  • Validators approve or reject proposed blocks
  • 1 day epochs divided into rounds
  • Shared redundancy across epochs
  • Consensus involves multiple communication rounds
  • Solana
  • https://solana.com/solana-whitepaper.pdf
  • master/save model
  • “Proof of history”
  • Master (aka leader) is selected to generate proof of history sequence
  • master orders message to be processed
  • Slaves (replicas) are the verifiers which execute transactions
  • Verifiers submit back to master
  • New master is elected when master is detected as a failure
  • 2/3 votes required (“super majority”)
  • Masters also called “PoH generators”
  • Randomly insert valid state hash and if validated as true the voters are slashed
  • AION
  • https://aion.network/media/en-aion-network-technical-introduction.pdf
  • Multichain
  • Interchain communication
  • Validators
  • Middlelayer connecting network validates transactions
  • 2/3 bridge validators must vote yes
  • Target blockchain must send confirmation to middlelayer, then middlelayer updates state to confirmed
  • Bridges are communication protocols to other networks
  • BFT-based
  • Must stake to validate
  • “Backers” are validator candidates on standby
  • “Solvers” solve a crypto puzzle provided by the network. “Proof of intelligence” is converted to backing
  • “Terms” are a round of when validators validate
  • Solidity contracts supported in mainnet
  • Java smart contracts in testnet
  • ThunderCore
  • https://docs.thundercore.com/thunder-litepaper.pdf
  • Master/slave model
  • Master is called the “accelerator”
  • Slaves are called “committee”
  • All transactions go to the master
  • Master produces blocks
  • Committee verifies blocks
  • 2/3 of committee must of agree on block
  • The network halts if master goes down
  • Network falls back to ethereum
  • Fallback is called “slow mode”
  • Nervos:
  • https://github.com/NervosFoundation/binary/blob/master/whitepaper/nervos-ckb.pdf
  • Generator: deterministic state transition function Cell:
    • a storage box
    • has an owner
    • can transfer ownership
    • can have permission to only allow certain users to write to it
    • output of generator is a new cell
    • a cell may one be used once as input to generator
    • a cell holds arbitrary data
    • cell owners can pay on behalf of users for tx fees Data Schema:
      • defines data structure of cell Validator:
      • defines validation rules of cells
      • creation, update, and destruction of cells can use different validation rules Transaction:
      • express transfer or update of cells Clients:
      • light clients do not perform state generator computations CKB:
    • general purpose Common Knowledge Base Nodes:
    • Archive nodes: a full node that validates txs, and keeps historical data
    • Consensus nodes: a node that processes txs (like an archive node) but does not store historical
    • Light nodes: interact with network, store limited data, can run on mobile devices

Amber Group

  • founded 2017 but ex Morgan Stanley, Morgan Sachs, Bloomberg people
  • 300+ billion trading volume since launch
  • raised 28 million in 2019 Series A, from Paradigm, Pantera, Polychain, Dragonfly, Fenbushi, Coinbase
  • Michael Wu CEO, Thomas Zhu CTO
  • Amber Pro is trading platform; OTC trading, earn yield on collateral, lend and borrow
  • has API

TODO reading

noia.network thetatoken.org rootstock ontology cardano neo zilliqa tezos grid boscoin eos iota qtum wanchain gxchain moac zencash bebulas Omniledger Algorand ChainSpace Dfinity https://dfinity.org/pdf-viewer/pdfs/viewer?file=../library/dfinity-consensus.pdf https://www.celer.network/doc/CelerNetwork-Whitepaper.pdf https://www.newtonproject.org/whitepaper/ https://quarkchain.io/QUARK%20CHAIN%20Public%20Version%200.3.5.pdf https://enigma.co/enigma_full.pdf https://github.com/holochain/holochain-proto/blob/whitepaper/holochain.pdf https://iolite.io/docs/iolite_witepaper_rev3.pdf https://hypernetwork.io/HypernetWhitePaper_v1.1.pdf https://static.metahash.org/docs/MetaHash_YellowPaper_EN.pdf?v=4 https://kadena.io/whitepapers.html https://agoric.com/ https://katallassos.com/ https://blink.network/ https://www.asure.network/ https://energyweb.org/ https://oceanprotocol.com/ https://edgewa.re/ https://vetri.global/wp-content/themes/vetri/documents/whitepaper.pdf https://www.decred.org/ https://people.csail.mit.edu/nickolai/papers/gilad-algorand-eprint.pdf https://github.com/Azure/coco-framework/blob/master/docs/Coco%20Framework%20whitepaper.pdf https://www.orbs.com/helix-consensus-whitepaper/ https://origo.network/whitepaper https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf https://web.stanford.edu/~nadal/A-Decentralized-Data-Synchronization-Protocol.pdf https://github.com/Constellation-Labs/whitepaper-business/blob/master/Constellation%20Labs%20-%20Business%20Whitepaper%20v1.0.pdf https://proxeus.com/en/ https://dos.network/ https://arxiv.org/pdf/1708.03778.pdf

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment