Future Gold
  • Future Gold
  • Future Gold
    • FGT Decentralized
    • Financial Inclusion
    • FGT Ecosystem
    • FGT Blockchain
    • How the Blockchain Works
  • BLOCKCHAIN STRUCTURE
    • FGT Algorithm
    • FGT Platform Structure
    • FGT Cloud Mining
    • FGT Digital Wallet
    • FGT Token Digital Wallet
    • Marketing Strategy
    • Marketing Team
  • AI Arbitrage Trade System
    • 1. Market Introduction
      • 1.1. The Origins
      • 1.2. Current Metrics
      • 1.3. Performance
      • 1.4. Projections
      • 1.5. Regulation
      • 1.7. Liquidity
      • 1.8 Volatility
      • 1.9 Spread
    • 2. Problem Description
    • 3. Arbitrage Trading
    • 4. Product Solution
      • 4.1. Future Gold Arbitrage Platform
      • 4.2. Beta Phase: Arbitrage Pairs Trading
      • 4.3. Stage 1: Arbitrage Pairs Trading
      • 4.4. Stage 2: Simultaneous
      • 4.5. Stage 3: Arbitrage Chain Trading
      • 4.6. Stage 4: Fully Decentralized
    • 5. Technical Details
      • 5.1. Blockchain
        • 5.1.1. Proof-of-Stake Consensus Mechanism
        • 5.1.2. Fully Decentralized
        • 5.1.3. Fastest Transaction Speeds in the Industry
        • 5.1.4. Low Transaction Costs
        • 5.1.5. Differences between Bitcoin and Future Gold
        • 5.1.6. Future Gold wallet
        • 5.1.7. Staking
        • 5.1.8. Staking Rewards
        • 5.1.9. Future Gold Blocks
      • 5.2. APIs of Cryptocurrency Exchanges
        • 5.2.1. APIs in General
        • 5.2.2. APIs in the World Wide Web
        • 5.2.3. APIs of Cryptocurrency Exchanges
        • 5.2.4. API Response Normalization
      • 5.3 Latency Reduction
        • 5.3.1. Why Latency Is a Problem
        • 5.3.2. Our Latency Approach
      • 5.4. Beta Phase: Prototype
        • 5.4.1. System Architecture
        • 5.4.2. Routing
        • 5.4.3. Latency
      • 5.5. Stage 1: Arbitrage Pairs Trading
        • 5.5.1. System Architecture
        • 5.5.2. Routing
        • 5.5.3. Latency
      • 5.6. Stage 2: Simultaneous Short-Long Strategy
        • 5.6.1. System Architecture
        • 5.6.2. Routing
        • 5.6.3. Latency
      • 5.7. Stage 3: Arbitrage Chain Trading
        • 5.7.1. System Architecture
        • 5.7.2. Routing
        • 5.7.3. Latency
      • 5.8 Stage 4: Fully Decentralized Arbitrage Trading
        • 5.8.1 System Architecture
        • 5.8.2 Routing
        • 5.8.3 Latency
    • 6. Conclusion
    • Task Center
      • How to get a task
      • How to complete the task
      • Task Center Frequently Asked Questions
      • Task center conditions and terms of use
  • BINANCE EDUCATION
    • Account Functions
      • How to Register on Binance App
      • How to Register on Binance with Mobile Number
      • How to Register on Binance by Email
      • How to Use Binance Referral Program
      • How to Disable My Account
      • How to Unlock My Account on Binance App
      • How to Unlock an Account
      • How to Convert Small Account Balance to BNB
      • How to Manage Sub-Account Functions and Frequently Asked Questions
      • How to Reset Your Binance Account Password
      • How to Generate Binance Account Statements
    • Identity Verification
      • How to Complete Identity Verification
      • How to Apply for Corporate Account
    • Two-factor Authentication
      • How to Enable Google Authentication (2FA) and Frequently Asked Questions
      • How to Solve 2FA Code Error
      • How to Reset Google Authentication on Binance App
      • How to Reset Google Authentication
      • How to Reset SMS Authentication on Binance App
      • How to Reset SMS Authentication
      • Supported SMS countries
      • Why Can’t I Receive SMS Verification Codes
      • How to Use YubiKey for Two-factor Authentication (2FA) on Binance
      • How to delete YubiKey for Two-factor Authentication (2FA)
      • How to Enable Binance Authenticator
    • Email Issues
      • How to Change Account Email
      • Why Can’t I Receive Emails from Binance
      • How to Whitelist Binance Emails
    • Referral & Affiliates
      • How to Redeem a Futures Bonus Voucher/Cash Voucher
      • How to Redeem Savings Trial Fund
      • How to Redeem a VIP Upgrade Voucher
      • Cashback Voucher Terms and Conditions
      • How to Redeem a Cashback Voucher
      • How to Redeem a Margin 0% Interest Voucher
      • How to Redeem a Voucher Code
    • Wallets
      • How to Check Balance and Transfer Funds on Wallet Overview
      • How to Connect Binance Extension Wallet (BEW) via Wallet Direct
      • Frequently Asked Questions on Binance App Funding Wallet Migration
      • Frequently Asked Questions on P2P Wallet to Funding Wallet Migration
    • Task Center
      • How to get a task
      • How to complete the task
      • Task Center Frequently Asked Questions
      • Task center conditions and terms of use
  • Created Wallet Address
    • Metamask Wallet Address
    • Connecting MetaMask to BNB Smart Chain
    • Add BUSD token in Metamask
    • Trust Wallet Address
      • Protect Your Crypto Wallet
      • Recovery Phrase or Private Key
  • FUTURE GOLD ACADEMY
    • IDO FUTURE GOLD FGT
      • Daily Gold Farms Future Interest
      • Daily Gold Farms Fixed Interest
      • Daily Gold Farms Compound Interest
    • Telegram Chat Id
    • How To Buy FGT
Powered by GitBook
On this page
  • Types
  • Integer
  • String
  • String32
  • SHA3
  • List
  • Pointer
  • Program
  • Value Destination 1
  • Merkle Root
  • Merkle Binary Tree
  1. BLOCKCHAIN STRUCTURE

FGT Algorithm

Types

LEB128 Little Endian Base 128 encoding for unsigned integers typically used to specify length prefixes for arrays and strings. Values in range [0, 127] are encoded in one byte. Larger values use two or more bytes.

Integer

A LEB128 integer with a maximum allowed value of 0x7fffffffffffffff (2 – 1) and a minimum of 0. A varint63 its into a signed 64-bit integer.

String

A binary string with a LEB128 prefix specifying its length in bytes. The maximum allowed length of the underlying string is 0x7fffffff (2 – 1). The empty string is encoded as a single byte 0x00, a one-byte string is encoded with two bytes 0x01 0xNN, a two-byte string is 0x02 0xNN 0xMM, etc

String32

A fixed-length 32-byte string typically used to encode hashes.

SHA3

SHA3 refers to the SHA3-256 function as defined in FIPS202 with a fixed-length 32-byte output.

This hash function is used throughout all data structures and algorithms in this spec, with the exception of SHA-512 (see FIPS180) used internally as function H inside Ed25519 (see RFC8032).

List

A List is encoded as a Integer-prefixed list of serialized items, one by one, as defined by the schema. The length prefix indicates the number of items that follow.

Pointer

A Pointer is encoded as a String32, and identifies another entry by its ID. Pointer restricts the possible acceptable types: Pointer<x> must refer to an entry of type X. A Pointer can be nil (not pointing to any entry), in which case it is represented by the all-zero 32-byte hash:

0x0000000000000000000000000000000000000000000000000000000000000000

Program

Program encapsulates the version of the FGT and the bytecode that should be executed by that FGT

FIELD

TYPE

DESCRIPTION

VM Version

Integer

The FGT version to be used when evaluating the program.

Bytecode

String

The program code to be executed.

Program encapsulates the version of the FGT and the bytecode that should be executed by that FGT

Inputs:

  1. program,

  2. arguments (list of strings),

  3. transaction version (integer).

FIELD

TYPE

DESCRIPTION

Ref

Pointer<issuance1|Spend1|Mux1>

Previous entry referenced by this ValueSource

Value

AssetAmount1

Amount and Asset ID contained in the referenced entry.

Position

String32

If this source refers to a Mux entry, then the Position is the index of an output. If this source refers to an Issuance or Spend entry, then the Position must be 0.

Value Source 1 Validation

Verify that Ref is present and valid. Define RefDestination as follows: If Ref is an Issuance or Spend: Verify that Position is 0. Define RefDestination as Ref.Destination. If Ref is a Mux: Verify that Mux.Destinations contains at least Position + 1 ValueDestinations. Define RefDestination as Mux.Destinations[Position]. Verify that RefDestination.Ref is equal to the ID of the current entry. Verify that RefDestination.Position is equal to SourcePosition, where SourcePosition is defined as follows: If the current entry being validated is an Output1 or Retirement1, SourcePosition is 0. If the current entry being validated is a Mux, SourcePosition is the index of this ValueSource in the current entry’s Sources. Verify that RefDestination.Value is equal to Value.

Value Destination 1

An Entry uses a ValueDestination to refer to other entries that receive value from the current Entry.

FIELD

TYPE

DESCRIPTION

Ref

Pointer<issuance1|Spend1|Mux1>

Pointer<issuance1|Spend1|Mux1>

Value

AssetAmount1

Amount and Asset ID contained in the referenced entry

Position

String32

If this source refers to a Mux entry, then the Position is the index of an output. If this source refers to an Issuance or Spend entry, then the Position must be 0.

Merkle Root

A top hash of a merkle tree (binary or patricia). Merkle roots are used within blocks to commit to a set of transactions and complete state of the blockchain. They are also used in merkleized programs and may also be used for structured reference data commitments.

Merkle Binary Tree

The protocol uses a binary merkle hash tree for efficient proofs of validity. The construction is from RFC 6962 Section 2.1, but using SHA3–256 instead of SHA2–256. It is reproduced here, edited to update the hashing algorithm.

The input to the merkle binary tree hash (MBTH) is a list of data entries; these entries will be hashed to form the leaves of the merkle hash tree. The output is a single 32-byte hash value. Given an ordered list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)}, the MBTH is thus defined as follows:

The hash of an empty list is the hash of an empty string:

MBTH({}) = SHA3-256("")

The hash of a list with one entry (also known as a leaf hash) is:

MBTH({d(0)}) = SHA3-256(0x00 || d(0))

For n > 1, let k be the largest power of two smaller than n (i.e., k < n ≤ 2k). The merkle binary tree hash of an n-element list D[n] is then defined recursively as

MBTH(D[n]) = SHA3-256(0x01 || MBTH(D[0:k]) || MBTH(D[k:n]))

where || is concatenation and D[k1:k2] denotes the list {d(k1), d(k1+1),..., d(k2-1)} of length (k2 - k1). (Note that the hash calculations for leaves and nodes differ. This domain separation is required to give second preimage resistance.)

Note that we do not require the length of the input list to be a power of two. The resulting merkle binary tree may thus not be balanced; however, its shape is uniquely determined by the number of leaves

Merkle Patricia Tree

The protocol uses a binary radix tree with variable-length branches to implement a merkle patricia tree. This tree structure is used for efficient concurrent updates of the assets merkle root and compact recency proofs for unspent outputs. The input to the merkle patricia tree hash (MPTH) is a list of key-value pairs of binary strings of arbitrary length ordered lexicographically by keys. Keys are unique bitstrings of a fixed length (length specified for each instance of the tree). Values are bitstrings of arbitrary length and are not required to be unique. Given a list of sorted key-value pairs, the MPTH is thus defined as follows: The hash of an empty list is a 32-byte all-zero string:

MPTH({}) = 0x0000000000000000000000000000000000000000000000000000000000000000

PreviousHow the Blockchain WorksNextFGT Platform Structure

Last updated 1 year ago