FANDOM

Thirdstage's Wiki
37 Pages
Add new page

On Blockchain

View source
Comments Share

General

Smart Contract

RAFT

Business Concepts

Entry Meaning Position Korean
Debit Right Side 차변
Credit Left Side 대변

Bitcoin

Ethereum

  • Ethereum Improvement Proposals (EIPs)
    • standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards
  • ERC
    • Application-level standards and conventions
API Description Reamrks
web3.eth.getTransactionReceipt Returns the receipt of a transaction by transaction hash.
web3.eth.blockNumber Returns the current block number.
web3.eth.getBlock Returns a block matching the block number or block hash
web3.eth.accounts Returns a list of accounts the node controls
web3.eth.getBalance Get the balance of an address at a given block
network component site remarks
Rinkeby homepage https://www.rinkeby.io/
faucet https://faucet.rinkeby.io/
explorer https://www.rinkeby.io/#explorer
Kovan homepage https://kovan-testnet.github.io/website/
faucet
explorer https://kovan.etherscan.io/

Go Ethereum

Ethereumj

Parity

Solidity

References

Readings

Grammar
Tools
misc

Libraries

Examples

Collections

  • awesome-solidity : A curated list of awesome Solidity resources, libraries, tools and more

solc-js

web3j

  • APIs and Classes 
                                               extends
                                            +------------ Ethereum
  JsonRpc2_0Web3j ---------------- Web3j ---|
                     implements             +------------ Web3jRx
                                               extends
Class Source API Remark
public class HttpService extends Service HttpService.java HTTP implementation of our services API
org.web3j.protocol.Service Service.java Base service implementation
public class JsonRpc2_0Web3j implements Web3j JsonRpc2_0Web3j.java JSON-RPC 2.0 factory implementation
interface org.web3j.protocol.Web3j Web3j.java extends Ethereum, Web3jRx
interface org.web3j.protocol.core.Ethereum Ethereum.java JSON-RPC methods
interface org.web3j.protocol.rx.Web3jRx Web3jRx.java
interface org.web3j.quorum.Quorum Quorum.java extends Web3j
org.web3j.tx.Contract Contract.java
org.web3j.protocol.core.RemoteCall<T> RemoteCall.java
org.web3j.protocol.core.methods.request.Transaction Transaction.java
abstract org.web3j.abi.TypeReference<T extends org.web3j.abi.datatypes.Type> TypeReference.java
org.web3j.abi.datatypes.Function Function.java

Truffle

  • Examples

Zeppelin Solidity

Embark

Mist Browser

Ganache CLI

Remix IDE

  • https://github.com/ethereum/remix-ide
  • Desc. : a browser-based compiler and IDE that enables users to build Ethereum contracts with Solidity language and to debug transactions
  • License : MIT License

Oraclize

  • http://www.oraclize.it/
  • Desc. : the leading oracle service for smart contracts and blockchain applications, serving thousands of requests for day every day on Ethereum, Bitcoin and Rootstock.
  • License :

Pantheon

Quorum

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

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

Eris

Tendermint

  • https://tendermint.com/
  • Desc. : Byzantine fault-tolerant replicated state machines in any programming language
  • License : ?

IPFS

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


Retrieved from "https://3rdstage.fandom.com/wiki/On_Blockchain?oldid=13559"