Skip to content

Instantly share code, notes, and snippets.

@johnzweng

johnzweng/Libra technical overview.md

Created June 19, 2019 12:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save johnzweng/8411704179e6d8f033ee359591bf5d67 to your computer and use it in GitHub Desktop.
Save johnzweng/8411704179e6d8f033ee359591bf5d67 to your computer and use it in GitHub Desktop.
Download ZIP
First technical view on Libra
Raw
Libra technical overview.md

First technical view on "Libra":

Author: Johannes Zweng (johannes@zweng.at) Date: 19.6.2019

Notes:

  • Will be a new blockchain, not based on an existing blockchain
  • Permissioned blockchain (not everybody can be a validator)
  • Core Software ("Libra Core") written in Rust (like for example grin or parity), avaiable here on github
  • Licensed under Apache 2.0 license
  • Currently only CLI interface, no GUI yet
  • Account-based (not UTXO-based), similiar to Ethereum
  • is a Smart contract platform, similiar to Ethereum
  • Concept of gasPrice, gasLimit similiar to Ethereum
  • Transactions can emit Events (to communicate with outside systems, like DApps (like in Ethereum)
  • The virtual machine where the code (contracts) will be executed in is newly developed from scratch: "MoveVM", code for the VM will be written in the language "Move" (also newly developed especially for this purpose)
  • MoveVM: a stack-based, statically typed virtual machine (see also this Readme.md for details)
  • List of supported Opcodes see here or here
  • Different to Ethereum the networks token is not low-level part of the VM specification but instead implemented as a "module" written in the Move language. See libra_coin.mvir
  • Smart contract code:
    • for comparison: in Ethereum code lives in Smart Contracts, which need to deployed on-chain first. Then the execution of the code can be triggered by sending a transaction or a message call to a contract.
    • in Ethereum transations only contain "data" which can be inspected and used by the code in the called contract (exception: during deployment transactions he content of the transaction data is executed as code which is expected to return the smart contract bytecode)
    • This is a little bit different here in Libra: every transaction can carry a transaction script which contains executable Move code
    • This transaction script only "lives" for the duration o the transaction (will not be persisted in the global storage/state)
    • Transaction scripts are excuted in the context of the calling account and can interact resources (modules aka Smart contracts) deployed in the global storage
  • Accounts:
    • Libra has already something similiar what Ethereum tries to achieve with "account abstraction"
    • Each account has an instance of the standard module called LibraAccount.T
    • this module stores basic account information like: balance, sequence number (like nonce on Ethereum), but also authentication key
    • this will make it possible to exchange the provate key, controlling an account (key rotation). See rotate_authentication_key.mvir
  • World state (aka "block header"):
    • each block the validators commit to (sign) the following data structure: ledger_info.proto
    • see this image for details how the state root is constructed: data.png (part of Storage doc)
  • Cryptographic details:
    • Libra uses also ECC (elliptic curve cryptography) for keys and signatures
    • but it uses a different curve than Bitcoin/Ethereum, namely: Ed25519 with the "PureEdDSA" signature scheme (see RFC 8032))
    • Altough the current signature scheme is already named as "legacy" in the code and apparently a switch to the ed25519-dalek impementation seems to be planned
  • Already present in the code (but as far as I se not used yet) is an implementation of SLIP-0010: key derivation to derive multiple keys from a single root key/seed (this something like BIP 32, but for coins using other curves than Secp256k1)
  • private keys are 256 bit long (like Bitcoin or Ethereum keys)
  • Addreses: addresses are simply the SHA3 hash of the public key (but different to Ethereum the hash is not truncated, but instead the full public key hash is used as address)
    • example for an address: 60275e4c8f2f77d79eb6b663f4f86a988631e2ea480bcb8f1f94e6aed5295a14
    • as far as I see, addresses do not contain any checksum?
  • Consensus Protocol:
    • it's called "LibraBFT", is a byzantine fault tolerance protocol (for example like Tendermint)
    • see the paper here for details
    • it's based on HotStuff
  • Validators' economic incentive:
    • LibraBFT describes how to detect dishonest validators, but doesn't fixate how the incentive for honest validators will look like (simply serach for "economic incentive" in the paper.
    • instead the incentive model will be implemented in a higher abstraction level, in the "execution module" (implmented in the Move language). Quote from the paper: "The execution of rewards and punishments is meant to be entirely delegated to the execution module of the Libra Blockchain and programmed using the Move language."
  • Validator set:

Resources:

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