Navigation

    Vite Forum
    • Register
    • Login
    • Search
    • Unsolved
    • Solved
    • Recent
    • Tags
    • Popular
    • Groups
    • Github
    1. Home
    2. admin
    A
    • Profile
    • Following
    • Followers
    • Topics
    • Posts
    • Best
    • Groups

    admin

    @admin

    SBP

    72
    Reputation
    50
    Posts
    378
    Profile views
    16
    Followers
    2
    Following
    Joined Last Online

    admin Follow
    Operator SBP

    Best posts made by admin

    • Vite Resources

      What is Vite?

      Vite is a next-generation Reactive Blockchain that adopts a message-driven, asynchronous architecture and a DAG-based ledger. The goal for Vite’s design is to provide a reliable public platform for industrial dApps, with features of ultra-high throughput and scalability

      Project Overview

      • Token Name: VITE

      • Release date: 2018-06-15

      • Total circulation: 1,000,000,000 (40% private equity / 25% ecological fund / 5% airdrop / 10% marketing / 20% team lock * for 2 years until June 15, 2020)

      • Private placement: 400,000,000 (issued)

      • Market circulation: 433,960,000

      • Project development phase: test network

      • Main Net online time: Q3 of 2019

        • White Paper
        • Vite Wiki and Documentation
        • Technology Blog

      Team Information

      • Team location: Beijing China and Silicon Valley USA
      • Total team size: 39 people
      • Number of developers: 24

      Investors

      • Bitmain
      • OK Blockchain Capital (OKCoin)
      • LinkVC
      • Node Capital
      • And more

      Exchanges

      • ViteX
      • Bittrex
      • Okex
      • Bilaxy
      • Binance

      Products

      • Vite official website
      • ViteX
      • Web Wallet
      • Desktop Wallet
      • iOS Wallet
      • Android Wallet
      • Explorer 1
      • Explorer 2
      • Vite Store

      Key product descriptions

      • ViteX Decentralized exchange: The new decentralized exchange created by Vite Labs. True Decentralization, asset security and seamless trading experience. You can trade to earn tokens, receive dividends, and contribute to the community.

      • Online version is now available: https://vitex.net/
        Detailed introduction: https://forum.vite.net/topic/925/the-revolution-of-dex-vitex

      • Vite Wallet: A multi-chain, multi-currency HD wallet developed by Vite Labs team. Currently, three public chains are supported: VITE, ETH, and Grin.

        • Universal download link: https://app.vite.net/
        • iOS: Available in iOS app stores
        • Android: https://play.google.com/store/apps/details?id=net.vite.wallet
        • Detailed introduction: https://medium.com/vitelabs/vite-wallet-app-101-d7e1d17e346c
      • VitePay & Vite Store: An E-commerce platform that allows users to purchase Vite inventories using VCP (Vite Community Point) issued on VITE public chain. Vite Store and VitePay are two important products that successfully demonstrate real-world blockchain use cases.

        • Link: https://global.vite.store/

      How can I get VITE?

      Currently, VITE is in the forms of VITE ERC20 tokens and native VITE. Before the main-net of VITE is officially released, it is VITE ERC20 tokens tradeable on the exchanges. However, on the present VITE public chain, there exists a part of VITE migrated to VITE public chain already, called native VITE.

      1. Purchase Vite on the exchange ( ViteX,Bittrex, Upbit, and OKex,Binance)
      2. Download the Vite App and every 24 hours, receive anywhere between 4 to 1,000 VITE as airdrop rewards
      3. Vote for official Snapshot Block Producer (SBP) in the Vite wallet. Refer to this article here for more detailed information: https://medium.com/vitelabs/vite-testnet-incentive-plan-744cf45a9d09
      4. Operate a SBP and get up to 600,000 VITE as block-producing rewards and/or staking & voting rewards
      5. Operate a full node and get a portion of the VITE mined by official Vite SBPs. More information can be found here: https://medium.com/vitelabs/full-node-incentive-program-will-be-kicked-off-on-december-13th-baa7fa1aa8c8

      MainNet

      • Vite MainNet Introduction
      • SBP Introduction
      • SBP Ecosystem Incentive Plan
      • How to register as an SBP
      • MainNet Full Node Incentive Program
      • Full Node Rewards
      • How to run a full node
      • What's a Quota
      • MainNet SBP FAQ
      • Community Experience
      • How to Convert Vite ERC20 onto VITE MainNet
      • How to Vote for official SBPs

      Social Media

      • Website
      • Twitter
      • Telegram
      • Vite Forum
      • Discord
      • Reddit
      • Bitcointalk
      • Medium
      • Youtube

      Technology development

      • Github: https://github.com/vitelabs
      • Technology blog: https://forum.vite.net/category/20/blog
      • MainNett Resource Manager: https://explorer.vite.net/
      • RPC documentation: https://vite.wiki/api/rpc/
      • Vite JS: https://vite.wiki/api/vitejs/

      Community projects:

      • High Roller
      • Dice Game
      • PokerFlip
      • Dog VS Cat
      • Roulette
      • Zootopia
      • Lucky 9
      • Classic Fruit Machine
      • VITE To The Moon
      • Lucky One

      FAQ

      • What is the Staking and PoW in vite?
      • Two things You Need to Know about Quota
      • FAQ List

      Forum Rules

      • About Reputations Points in Vite Forum
      posted in About Vite
      A
      admin
    • Vite in a nutshell

      Introduction

      As mentioned in our white paper, Vite uses DAG (directed acyclic graph) technology for its core ledger structure, which stores transaction information for every account.
      In order to improve the data security of the whole DAG ledger and make it tamper-resistant, Vite has created the concept of Snapshot Chain.
      Since the white paper is abstract, this article hopes to describe the core DAG ledger structure and snapshot chain with the help of 500 lines of code.

      Core Concept

      1. The DAG ledger structure of Vite
      2. The snapshot chain of Vite

      The DAG Ledger Structure of Vite

      af8c9752-3440-4bfe-87b8-d250e0e30925-image.png

      Vite's design made a trade-off between two aspects, reduction of false fork ratio and tamper resistance.

      The above figure shows the performances of false fork and tamper resistance in several blockchain ledger structures, also described in the white paper.

      Vite decided on the block-lattice of DAG. The following paragraphs describe the block-lattice of DAG structure in more detail.

      3ebf232d-adad-4640-8748-e33d8c1c5304-image.png

      In the figure above, S stands for the state of the world, and there are 3 initial accounts A, B, C. The status of these accounts are A0, B0, C0. Solid arrows point from the current status of a given account to the previous status of said account, and dotted arrows indicate any indirect impact (e.g. caused by transfers) between the statuses of different accounts. Assume that in the initial status, the balance of accounts is $100 each,

      1. Initial state of the world: S1={A0=100, B0=100, C0=100}
      2. After account B transferred $20 to account A, state of the world : S2={A1=120, B1=80, C0=100}
      3. After account A transferred $30 to account C, state of the world : S3={A2=90, B1=80, C1=130}

      In Vite, every account status is a block (such as A0, A1, etc in figure); reference relationship among blocks (arrows in figure) is the transfer process among accounts.

      The entire history of transactions among accounts is represented by a directed acyclic graph, or DAG.

      The Snapshot Chain Structure of Vite

      The DAG chain, which is composed of account blocks, can explicitly describe the change of world status. However, the frequency of transactions for a given account affects the length of the relevant chain, and an account chain with infrequent transactions is easy to be tampered with.

      To solve this problem, Vite introduces snapshot chain that grows continuously, thereby increasing the tamper-resistant level of the block-lattice structure.

      22f9a564-3baa-41f4-b654-0e3a090f3f5e-image.png

      The above describes the world status of 3 accounts: S1, S2, S3. The arrow direction shows the previous status of the current status. The above structure is basically the snapshot chain, where every block represents the state of the world (A set of all account statuses), and each block references the previous one. Of course, in order to reduce storage, each block only contains the change between successive states of the world, as shown below. Also, the blocks are generated on a fixed schedule; so not every transaction generates a snapshot block.

      f0adc170-2eed-4b5b-8f4d-eeee4512a298-image.png

      Implementation of Code

      The context above gave a brief introduction of DAG ledger and snapshot chain structure of Vite. The following sections implement these two data structures as well as the process of transfer and snapshot generation via code.

      Data Structure

      Transfers among ledgers are made through transactions, the code below defines the data structure of a transaction:

      7e43b3a0-7572-45b1-b13d-ad1cf3d70936-image.png

      There are two types in TxType, representing send and receive transactions separately. These are corresponding to the fact that in Vite, a transfer generates two transactions.

      Below is the data structure of account status, we can see that the account status references the transaction data Tx. This means that every change in account status is caused by a transaction.

      Send accounts reference TxType as send transaction and receive accounts reference TxType as receive transaction.

      e022c477-29ab-44fe-9e48-886e48793c67-image.png

      Account status will be snapshotted by snapshot chain periodically, the definition of snapshot block is as below, Height param means the height of snapshot block, and it increments by 1 each time. AccountsHash represents all the hashes of cached account status.

      7c4b59e4-dde5-4eb9-b541-4f79efe3a2d5-image.png

      The context above describes the fundamental data structure that constitutes Vite. The following sections of transfer transactions and snapshot block generation are based on these data structures.

      f3adf2a9-35b7-4c7d-adf7-792e313579c0-image.png

      These two data structures represent the Vite account chain and snapshot chain respectively.

      AccountStateBlockChain is a map data structure, key is the address of each account, value is a linked list of AccountStateBlock, pointing to the previous block via PreHash.

      Transaction Process

      Send Transaction

      5e834145-1032-40b1-aad0-44e36410185f-image.png

      The core code of the send transaction is as shown above:

      1. Construct a transaction and sign the transaction
      2. Pack the account status block and sign the packaged account status block
      3. Insert the account status block into the account chain and broadcast the block results

      Receive Transaction

      e2b265ef-431b-4bfb-afb3-e5b79b29aa7b-image.png
      There will be a coroutine waiting for the broadcast event to be generated and verify the validity of the block. Meanwhile, if it needs to generate the corresponding received transaction, it will forward Tx to the corresponding node.

      a531a9d3-eaa8-4d91-a06b-6de17f33823a-image.png

      After the corresponding node receives the send transaction and passes the verification:

      1. Generate a received transaction and sign it
      2. Pack the account status block and sign the packaged account status block
      3. Insert the account status block into the account chain and broadcast the block structure

      The Snapshotting Process of Snapshot Chain

      63dca424-3401-4c4d-80bc-a2c0295d44ac-image.png

      The mining account will periodically generate the snapshot block and insert it into the snapshot chain.

      Summary

      The key point of this article is to briefly introduce the main process of naive-vite, and at the same time let everyone know the fundamental principles of Vite through this simple demo.

      For more details, visit official Vite website and vite blog, and watch the official implementation of the first version on Github.

      References

      • The white paper of Vite
      • Source Code of naive-vite
      • Block-tutorialhttps://vite.blog/images/pasted-viteshan-15.pnghttps://vite.blog/images/pasted-viteshan-16.pnghttps://vite.blog/images/pasted-viteshan-17.pnghttps://vite.blog/images/pasted-viteshan-18.pnghttps://vite.blog/images/pasted-viteshan-19.pnghttps://vite.blog/images/pasted-viteshan-20.pnghttps://vite.blog/images/pasted-viteshan-21.pnghttps://vite.blog/images/pasted-viteshan-22.pnghttps://vite.blog/images/pasted-viteshan-23.pnghttps://vite.blog/images/pasted-viteshan-24.pnghttps://vite.blog/images/pasted-viteshan-25.pnghttps://vite.blog/images/pasted-viteshan-26.png
      posted in Tech News & Updates
      A
      admin
    • The Selection of Security Algorithm of Vite

      Introduction

      Asymmetric encryption, Hash and other security algorithms are the cornerstone of the blockchain. Among many implementations of security algorithms, how does Vite choose?

      A. Digital Signature Algorithm - Ed25519

      Background

      The purpose of the digital signature is to create non-repudiation, a key characteristic of a wet signature (one we sign on paper contracts). The core feature of an effective digital signature is that the signer will be clearly identify based on the signed message, because the signed message can only be produced by relevant private key holders. Digital signature is legally enforceable in some countries, for instance, the Electronic Signature Act in USA and Signature Act in Germany.

      The public key and the private key play critical roles in the process of signing with the private key, publishing the public key, and sending the message and its signed version for validation purposes. The pair tends to appear together, and is sort of inseparable like quantum entanglement. Public and private key are commonly generated through a special one-way function and a random number. The complexity of solving the one-way function f(x) = y is equivalent to that of solving polynomials, while solving the inverse function, f<sup>-1</sup>(y) = x, is exponential difficulty. The cost of calculating a private key from a public key exceeds the capability of any modern computing systems. The signature model is safe enough by now. However, if quantum computers are available in the future, then the current asymmetric encryption mechanism including RSA, DLP (Discrete Logarithm Problem) or ECC (Elliptical Curve Cryptography, expanded from DLP) will not be safe anymore. In other words, the attainment of quantum security will probably take as long as the invention of quantum computers.

      The signature algorithm, on which the generation of account addresses and transactions is all based, is essential for the blockchain system. To select a signature algorithm, we need to evaluate the algorithm's security and performance, where security is the more important concern. Satoshi Nakamoto selected "ECDSA over secp256k1". Secp256k1 was a Koblitz curve defined by SECG. Before Nakamoto's paper, the algorithm wasn't really used by anybody. "ECDSA over secp256k1" is designed transparently, while the "secp256r1" curve (the more mainstream P256 algorithm) used by NIST has weird parameters, which are widely recognized as the back door arranged by NSA. A series of subsequent incidents clearly proved the vision of Nakamoto's choice, which was picked up by Ethereum and EOS.

      However, with the expiration of patent Ed25519, both the core developers of Bitcoin and Vitalik Buterin had talked about transfer to Ed25519. Despite their preference for Ed25519 as indicated in the documents, the porting cost was too high to execute the transfer. Whereas, Ripple made such a migration in 2014 without any hesitation.

      Consideration of Security

      Ed25519 was considered "safe" after being tested and reviewed by many independents and well-known security professionals, while secp256k1 was deemed "unsafe." Here is the reference.

      Consideration of Performance

      To satisfy the industrial application requirements for high throughput, low latency and good scalability, Vite has designed several optimization schemes, including introducing the concept of "transaction decomposition" which means to decompose a transaction into a "Request" and a "Response." As such, verification and confirmation can happen quite frequently, and therefore the performance of the whole system is especially sensitive to the speed of both signature algorithm and signature verification process. The matter of this speed is especially important given Vite's high TPS target. According to recent data, the performance of Ed25519 is several times faster than ECDSA over secp256k1 (Reference: the benchmark built by Ripple). We believe that the speed boost will greatly improve the performance of Vite system. In addition, the signature of Ed25519 is slightly shorter than that of ECDSA, which reduces the pressure of the network transmission and the storage system.

      For more detailed benchmark, check Reference.

      Modification

      Instead of using SHA2 in Ed25519, Vite uses Blake2b.

      Deficiency

      Since the key space is non-linear, the system is unable to be compatible with Hierarchical Deterministic Key Derivation of BIP.


      B. Hash algorithm - Blake2b

      Background

      The purpose of a hash algorithm is to generate a short, fixed-size summary from any long message. The Hash function is also one-way. But the difference between a hash function and the one-way function of asymmetric encryption system is that the latter function usually seeks a reverse solution, which is practically impossible while theoretically possible. That is to say, a public key includes all the information that is needed to generate the private key. However, a hash function is not theoretically reversible but is practically reversible. A hash has infinitely many source messages corresponding to it, and here is an example: If a hash function's output is n bits, then the amount of all the output will be 2<sup>n</sup>, but there is an infinite amount of possible inputs. According to the pigeonhole principle, If the input preimage is m * 2<sup>n</sup> bits long and the output of the hash function is evenly distributed, the probability of an X which allows Hash(X) = target being the preimage is 1/m(if not evenly distributed, the probability is even lower). In practice, however, the source text will not be too long, due to limited storage and computing power. Generally, if the input isn't very long, then the range of m will not be wide. So the X that makes Hash(X) = Target will probably be the real source message.

      In the Vite system, the hash function is responsible for mining, data tamper-proofing, data protection etc. It is as fundamental as the signature algorithm, so we will seriously consider about the security and the performance of hash algorithm.

      Security Consideration
      Blake2 evolves from Blake. Blake lost when competing with keccak for SHA3 standard. The reason was that Blake and SHA2 are similar to each other, while NIST aimed at a Hash algorithm which was totally different from SHA2 standard.

      desire for SHA-3 to complement the existing SHA-2 algorithms … BLAKE is rather similar to SHA-2.

      NIST appraised Blake quite highly:

      “BLAKE and Keccak have very large security margins.”。

      So we assume that the level of security between Blake2 and keccak are similar.

      Performance Consideration

      According to a massive amount of data, Blake2 beats any other Hash algorithm on generic CPUs(X86 ARM and etc.). For detailed performance, check Reference.

      Another characteristics of Blake2 is that, the peak value of Blake2 algorithm designed by ASIC wouldn't be very high, which means the peak speed of mining is relatively low.


      C. Key Derivation Function - scrypt

      Background

      In simple terms, Key Derivation Function is used to derive sub-private keys from a master private key. One example is to expand a short string to a required format through the KDF algorithm. KDF is similar to hash, with a difference of adding random variables to prevent being hacked by table-lookup attacks (e.g. rainbow tables). The scrypt we used is a memory-dependent KDF so every calculation takes up significant memory and time. So brute force attack is nearly impossible.

      KDF is non-fundamental in our system. After converting the short variable-length keyword input by users through KDF and receiving keys of 256 bits, we use the keys along with AES-256-GCM algorithm to encrypt Ed25519 private keys so that those keys will be securely saved in personal computers.

      Reasons

      From a technical perspective, there is no significant change between scrypt and argon2, which won 2015 Password Hashing Competition. But scrypt is more mature from a practical perspective because it was born earlier and used more widely. If there is no critical problem of argon2 in the next 2 to 3 years, we would consider keep using it.


      D. Relative terms

      • "ECDSA"(Elliptic Curve Digital Signature Algorithm) is a digital signature algorithm using elliptic curve

      • "secp256k1" is a parameter of ECDSA algorithm

        • "sec" is Standards for Efficient Cryptogrpahy introduced by SECG(Standards for Efficient Cryptography Group)
        • "p" means the elliptic curve uses prime field
        • "256" means the length of the prime is 256 bits
        • "k" stands for Koblitz Curve
        • "1" means it is the first(only on actually) standard curve type
      • Ed25519 is a EdDSA Signature algorithm using SHA512/256 and Curve25519

      • NIST(National Institute of Standards and Technology) develops security standards like SHA3, P256 and etc..

      • NSA stands for National Security Agency

      • AES-256-GCM is an advanced encryption standard with 256-bits key in Galois/Counter Mode

      posted in Tech News & Updates
      A
      admin
    • A brief analysis of MPT and its application in Ethereum

      Introduction

      The data structure of Ethereum ledger is a blockchain list, which is the original data structure of blockchain. Nowadays, some other data structures are derived such as DAG (Directed acyclic graph). In Ethereum, mining is a way to generate a block, the right to "mine" a block is that each node gets a fair competition through the PoW mechanism. The data contained in each block can refer to the Ethereum yellow paper, transaction list is included in these data. Transaction list is represented by a data structure called MPT (Merkle Patricia Tree) in Ethereum. MPT is evolved by Trie Tree and Merkle Tree, hence it has the characteristics of both of them.

      Trie Tree

      To get a better understanding of MPT, we should get to know about Trie Tree first. Trie Tree is a kind of dictionary tree, the figure below is a Trie Tree structure:
      ad520ee9-cb35-4e34-a8ac-cc2df408b7ee-image.png

      Trie Tree is extremely simple and easy to understand. The Trie Tree above represents the string collection of ["AOT"、”BR"、"DCA"、”DCB"], the path from root node to leaf nodes represents an element of string collection. For example, the leftmost path means "AOT". It is also good for Trie Tree to organize key-value pairs. Key is a string that represented by the path from root node to leaf nodes, value is put or points to value by pointer in leaf node. Searching for a value by key has constant-level time complexity.

      Patricia Tree

      In order to save space in Ethereum, they actually use the optimized Trie Tree, which means Patricia Trie (Compressed prefix tree), as shown below
      4c22dc6e-ffa3-4c82-b393-b8bcd4a8cc8c-image.png

      On the basis of Trie Tree, Patricia Trie merged child node with parent node who has only a single child node. The advantage is that it is more space-saving. However, the disadvantage is that it is slightly more complicated than Trie Tree when inserting. In some cases, it is necessary to do node segmentation, For instance, if we insert a string "AOB" in the above tree structure, then the node "AOT" will be split into two nodes "AO" and "T", the tree structure will be like the following figure:
      13309334-427f-4f75-a355-70276376c5bc-image.png

      Patricia Trie is a bit more space-saving than Trie Tree.

      Merkle Tree

      Another data structure is Merkle Tree, an important data structure of blockchain which has been applied in SPV (Simplified Payment Verification). The following part is a brief introduction to the Merkle Tree. The structure of the Merkle Tree is as follows:
      8908913d-3ac9-4c95-90a3-bc5491633aeb-image.png

      Merkle Tree is also called Hash Tree, a kind of binary tree. Each node of this tree stores hash value, and only leaf nodes have data contained just like [A、B、C、D] shown above. The value of leaf node comes from the hash calculation on its associated data while the value of parent node comes from the hash of the concatenated hash strings of two child nodes. The hash process repeats recursively on every node until the hash of root node is computed. As a result, in a Merkle Tree whenever a change occurs in any leaf node the root node hash will change accordingly, which is known as its most important feature.

      Given that root node hash is trustworthy, it is easy to verify whether some data is reliable or not, by acquiring a few necessary hashes of sibling nodes who are in the path from the certain leaf node to root. As shown below:
      0d6cf267-adf1-4234-b04c-4838951ced18-image.png

      For example, we could validate B by given H7 (root hash) from trusted source and B, H1, H6 from untrusted source. Firstly we compute H5 by Hash(H1+Hash(B)), then we could confirm data B's correctness by judging H7 == Hash(H5 + H6). One characteristic of hash function is that it leads to unpredicted and significant variation in the hash result even if source data has only a slight change, therefore it is extremely difficult to forge B, H1, H6 simultaneously to figure out H7. As a result, we can verify the correctness of B, H1, H6 as long as H7 is reliable. This kind of verification process can be categorized into the realm of Zero-knowledge proof.

      Merkle Patricia Tree

      Since Patricia Trie has a simple structure and is easy to search and Merkle Tree supports zero-knowledge proof, MPT is evolved by optimizing Patricia Trie and Merkle Tree with the merits of both. The below figure shows a MPT structure:
      e4540155-cfaa-4577-80ba-5270d404129b-image.png

      MPT is actually a Patricia Trie which is easy to store key-value data set. Meanwhile it has the feature of Merkle Tree, figuring out the root hash by recursion, and the change of any node content will lead to the change of root hash.

      In MPT, there are 3 kinds of nodes, Leaf Node, Branch Node and Extension Node. Each of them has its own functions. Leaf node stores the value itself or the pointer that points to the value. Branch node has function of router. For example, the figure above has 16 characters [0…f] in total and each character is mapped to one pointer referencing to an independent child node. It's rapid to locate the correct subtree to continue when searching for a key. The extension node is a space-saving router node which merges the parent node that has only one child node with its child node. For another example, key ADGHJ is composed of 4 branch nodes and 1 leaf node, where A, D, G, H are branch nodes. However, by involving the concept of extension node we can merge ADGH into 1 extension node, plus 1 leaf node J to save space.

      Ethereum source code shows the root hash calculation in MPT is very similar to that in a Merkle tree. During a depth first search(DFS) traversal, data hash is calculated on the data associated with leaf node encountered, where the data object is serialized into a binary array and then the binary array is hashed. The hashing process on a branch node is to replace the pointers with the hash values of the child nodes, and then serialize them into a binary array for hashing. Extension node has the same hash process as branch node. After DFS is completed, the hash of each node is generated(including root node). Once any node in the tree changes data content, it is not necessary to traverse all the nodes for root hash value, but just only to recalculate the hash value of each node in the path from the node to the root node and its siblings.

      MPT is widely used in Ethereum. Transaction lists, receipt lists, state of the world and contract data are all organized by MPT. To be brief, all key-value data are basically organized by MPT.

      Taking the state of the world as an instance, it is represented as a key-value set structure. The key is account address and the value is a 4-tuple value: [nonce, balance, storageRoot, codeHash](the specific meaning of each field could refer to Ethereum yellow paper). In Ethereum, the state of the world stores status message of all accounts among the whole network for a certain moment. The status of accounts may change when transactions occur or smart contracts are running. MPT is employed to help generate new hash value with less calculation during status changing. Furthermore, account status from untrusted source can be swiftly verified as long as reliable root hash is present. In addition, MPT is essentially a Patricia Trie, so account status can be quickly searched by address. Thanks to MPT, Ethereum node is able to only store transaction list root hash, receipt list root hash, world state root hash and contract data root hash in block header, and store or transfer the detail data information and block header separately, making a lightweight node possible.

      In summary, MPT has unique advantages in storage of key-value data, such as search-in-ease, incremental root hash calculation as well as zero-knowledge proof support.https://vite.blog/images/pasted-lyd00-14.pnghttps://vite.blog/images/pasted-lyd00-15.pnghttps://vite.blog/images/pasted-lyd00-16.pnghttps://vite.blog/images/pasted-lyd00-17.pnghttps://vite.blog/images/pasted-lyd00-18.pnghttps://vite.blog/images/pasted-lyd00-20.png

      posted in Tech News & Updates
      A
      admin
    • Story of Our Global Family: IC_Node

      Story of Our Global Family: IC_Node

      Supernode | Snapshot Block Producer (SBP) | Community Builder

      From Beijing to San Francisco to Russia… Who is IC_Node?

      As our Supernode and Snapshot Block Producer (SBP) programs gain momentum, Vite Labswould like to highlight IC_Node, another one of our fantastic Supernode operators! We hope that this conversation with our friends from Russia will inspire Vite supporters from around the world. Becoming an SBP is a rewarding path to joining the Vite ecosystem.

      The story behind IC_node shows the global reach of Vite’s family. Alexander Chuienko, leader of IC_Node, discovered Vite through his friend Oleg who is our Community Manager. After some action oriented dialogue, Alexander launched his Supernode with ambitious plans in mind. IC is an abbreviation of Institute Capital, which is a venture capital fund which he started in order to invest in blockchain technologies. Alexander is an investor in several projects, however, he runs only one Supernode.

      Alexander spends his free time running an extensive community of cryptocurrency and blockchain enthusiasts through Telegram and other means. Our intention is to collaborate in Russian and Ukrainian markets in the future, and Vite remains a strong ally to IC_Node and to any others interested in the Supernode and SBP programs.


      Care to get involved and earn rewards, from running a Supernode to becoming an SBP?

      Check out our article entitled Supernode 101 | Earn Vite Rewards Daily. This is a 4 minute read and all necessary information is provided. Take a look at our Node List for examples of existing SBP’s.

      https://www.vite.org/nodeList


      Done cool things on Vite? Want a shoutout?

      If you identify as one of the profiles below, contact Luke Kim, our Chief Marketing Officer. We would love to hear your story and jam out on ways to collaborate!

      1. a Supernode and/or SBP
      2. a builder of the Vite community and ecosystem internationally
      3. a developer on Vite

      We can support you to run community campaigns (e.g. subsidizing your token awards), to get press and to organize events locally (e.g. hackathons and educational workshops).

      We will be highlighting various SBP’s and community leaders in the future. Stay tuned!


      Official: https://www.vite.org/

      Telegram:

      • English: https://t.me/vite_en
      • Chinese(中文): https://t.me/vite_zh
      • Russian: https://t.me/vite_russia
      • Korean: https://t.me/vite_korean
      • Vietnamese: https://t.me/vite_vietnamese
      • Thai: https://t.me/vite_thailand

      Twitter:https://twitter.com/vitelabs

      Discord:https://discordapp.com/invite/CsVY76q

      Reddit:https://www.reddit.com/r/vitelabs/

      posted in General
      A
      admin
    • RE: How to create a Question Topic?

      Submit a topic as question topic

      3b779b37-1cf4-4739-b5ca-a6425eef8829-image.png

      Mark a answer as a correct answer

      a97dffa3-deb2-4d4c-9ad5-2b0432bc44c3-image.png

      posted in Support
      A
      admin
    • Vite P2P Network

      Introduction

      P2P is generally called peer-to-peer network. In comparison to the traditional C/S architecture, P2P has following features:

      1. Decentralization. Dispatched center and database does not exist in P2P network.
      2. Each of the nodes contains the same logic and state<sup>1</sup>, There is no concept of client or server.
      3. Unreliability. The connections between nodes are unreliable.

      C/S Architecture
      C/S Architecture

      P2P Architecture
      P2P Architecture

      P2P architecture is naturally suitable for decentralized blockchain network.

      [1] Note that this only happens at the network layer. In upper layers such as the application layer, nodes will have different roles between full nodes and lightweight nodes.

      Structured Model and DHT

      Since P2P networks are decentralized and do not have a central database, nodes can join and leave at any time. As such, resource allocation becomes a major issue. The strategy to locate resources quickly and effectively is known as content routing.

      In search of a solution, the P2P network model has evolved through several different forms, including centralized, pure distributed, hybrid, and structured<sup>2</sup>.

      • Centralized model uses master index, distributed storage and strong-dependency index server. This model is not reliable enough.
      • In pure distributed model, nodes and resources are randomly distributed and disordered, therefore could suffer from message flooding and storms in ease.
      • Hybrid network contains a combination of super nodes and ordinary nodes, where super nodes are more likely to dominate the network.

      The structured P2P network is generally based on a distributed hash table (DHT), which hashes the resource to obtain the resource ObjectID and allocates NodeID to every node in the network. Ideally, ObjectID is correspondent to NodeID and resource i is stored in node i 3. In this way, node n can directly request node i for resource i.

      Sorting NodeIDs by certain rules is a helpful for performance enhancement. In this scenario, if node n does not have the information of node i, it will first request from the neighbors of node i to reduce route hops and improve efficiency.

      In structured model, mapped nodes and resources are recorded in DHT. The network load is more balanced with better scalability.

      [2] Network Model Reference: https://en.wikipedia.org/wiki/Peer-to-peer

      [3] In actual implementation, resources are stored in mapped nodes and their neighbors to improve redundancy

      KAD

      DHT has many algorithm implementations, such as Chord<sup>3</sup> Pastry<sup>4</sup> CAN<sup>5</sup> and KAD<sup>6</sup>, etc.

      Vite adopts KAD, the most popular DHT algorithm nowadays. Configurable ED25519 public key is used as NodeID.

      [3] Chord Reference: https://en.wikipedia.org/wiki/Chord_(peer-to-peer)

      [4] Pastry Reference: http://www.freepastry.org/PAST/overview.pdf

      [5] CAN paper: http://www.icir.org/sylvia/thesis.ps

      [6] Kademlia paper: https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf

      The following are the primary ideas of KAD algorithm:

      1. Using XOR to calculate the logical distance between two NodeIDs.
      2. Each node saves N K-buckets, where N is the bit number of the NodeID and K can be adjusted on demand. The distance between current node and nodes in the i-th K-bucket lies between 2<sup>i</sup> and 2<sup>i+1</sup>.

      alt text

      All nodes are assigned to N subtrees, and K nodes are selected from each subtree and stored in the corresponding K-bucket.

      When node A requests resource i, given A XOR i is equal to d, node A may search from the log<sub>2</sub>d K-bucket and request resource i directly if node i is found.

      Otherwise, a parallel query should be performed within the K nodes. In this process, these nodes return the K nodes who are nearest to node i in distance in their K-buckets to node A, thereby locking the position of node i gradually.

      Algorithm complexity of KAD is O(log n)

      KAD summary

      KAD has the following advantages over other algorithms such as Chord:

      1. Easy to implement
      2. Flexible enough (N, K and parallel requests can be altered)
      3. Excellent fault tolerance and scalability

      Necessary adjustment is acceptable in real application implementation. For example, Vite NodeID has 256-bit length, but the K-bucket number is less than 256.

      Node communication

      There are 4 types of messages:

      1. PING To test a node is online or not
      2. STORE Require nodes to store data
      3. FIND_NODE find a node
      4. FIND_VALUE find a resource. similar to FIND_NODE

      Currently there is no requirement for STORE message (the block synchronization logic has been implemented in Vite Wire Protocol layer, not in p2p layer). PING and FIND_NODE are most used in Vite.

      Node discovery

      When a new Vite node initiates, it queries pre-configured bootnodes for its location first and then repeats this query on the nodes returned by bootnodes, until no closer nodes are returned. By then, the K-buckets of this node has been built successfully.

      Node maintenance

      Because nodes may change frequently, KAD uses the following strategies to maintain K-buckets.

      • The nodes in each bucket are arranged in reverse order by the most recent communication timestamp. The most recent contacted node is attached at bucket tail.
      • Once there is an incoming communication request, the algorithm goes to check if the request node is already in bucket in following steps,
        • If it exists, move it to the tail of the bucket.
        • If it doesn’t exist and the bucket is not full, put it at the head of the bucket.
        • If it doesn’t exist and the bucket is full, try to PING the head node(the longest un-communicated in bucket) and discard the new node if success, otherwise, replace the head node with new node.

      This strategy guarantees that nodes are updated in time. The more active the nodes are, the less likely for them to be replaced. In the meantime, the network is more stable.

      Summary

      Vite has chosen a proven P2P network solution, where Vite communication protocols such as transactions, block broadcasting and node synchronization are built.

      posted in Tech News & Updates
      A
      admin
    • RE: New user here, don't understand concept of staking or PoW to allow voting.

      @plasmo the web wallet pow is power by our gpu server.

      posted in Support
      A
      admin
    • RE: [SBP Proposal] Snap Secure -  Dec 24, 2018 - Past, Present and Future

      I think a php Sdk would be good for vite🎃

      posted in SBP Proposals
      A
      admin
    • RE: Snap Secure is Developing a Coin Faucet!

      good job. 🎃

      posted in Community Collaborations
      A
      admin

    Latest posts made by admin

    • RE: Can't withdraw ETH

      Can you give more details? About withdraw and deposit, please submit a ticket at here: https://vitex.zendesk.com/hc/en-001/requests/new

      posted in Questions
      A
      admin
    • RE: How to Convert ETH-000 to Ethereum Coin

      ETH-000 is the coin issued by Vite Labs, it can be convert to ETH 1:1.

      About deposit and withdraw eth, you chan check here: https://forum.vite.net/topic/2654/vitex-mobile-terminal-operation-guide/2

      posted in Questions
      A
      admin
    • RE: Promotion Assist Project

      @BD_VGATE said in Token Promotion Assist Project:

      Re-tweet pls https://twitter.com/VGATE2/status/1158361426211168257

      Done.

      posted in Operator Introduction
      A
      admin
    • RE: Promotion Assist Project

      @BD_VGATE Notice: the Re-tweet service currently is free for operator. In the future we maybe charge a service fee or the operator can airdrop some coin to our users.

      posted in Operator Introduction
      A
      admin
    • RE: [ANN][PASC]PascalCoin: 1600TPS, POW, CPU, ASIC-resistance.

      @Dzoelx I'll have a try.

      posted in Token Issuance & Listing
      A
      admin
    • RE: [ANN][PASC]PascalCoin: 1600TPS, POW, CPU, ASIC-resistance.

      @Dzoelx Great project. The iOS wallet is only on the beta test?

      posted in Token Issuance & Listing
      A
      admin
    • RE: [ANN][TERA]TERA PLATFORM: DApp, PoW, CPU, 1000 TPS

      The title is not the right format. It should be [ANN][TERA]TERA PLATFORM: DApp, PoW, CPU, 1000 TPS

      posted in Token Issuance & Listing
      A
      admin
    • RE: Introduction of ViteX Operator [Vite Online]

      @ViteOnline Will you offer Gateway Services ? Please put the gateway info on the topic.

      posted in Operator Introduction
      A
      admin
    • [ANN][VX]ViteX Coin: The native token of ViteX

      Token Information & Economics

      1. Token Name: ViteX Coin

      2. Symbol: VX

      3. Total Supply: 100,000,000

      4. Circulating Supply: 0 (up to July 30,2019)

      5. Operator: Vite Labs

      6. Native Token on VITE: YES

      7. Explorer: https://explorer.vite.net/

      8. Token Allocation: 90% to community; 10% to Vite Labs

        c7ec6ecd-6e7e-4143-a90d-e7197eb56bda-image.png

      9. Please provide a list of team wallets that hold your token. N/A

      10. Please provide all lockups in place for any holders of the token. N/A

      11. Are you compliant in all jurisdictions that you service and operate in?

      12. Please provide a detailed token migration plan. What mechanism will you be using? N/A

      13. What is the exact timeline of opening the swap/bridge to the public? Will you be able to complete this prior to the end of the voting period? If yes, please provide evidence that it the swap/bridge is ready or close to being ready.

      14. If your tokens currently still sit in only 1-5 addresses, please provide the timing of when they will be fully allocated to users.

      Project Summary

      1. Project Name: ViteX

      2. Project Website: https://vitex.net/

      3. White Paper: https://dex.vite.wiki/zh/dex/

      4. Roadmap: (Share a link or image of your roadmap)

      5. Link to your asset page on Vite network

      6. A one-sentence pitch about your Project: ViteX is an Exchange by the community, of the community.

      7. What are you planning to achieve with your project?

      8. What is the team size now?

        Please list each core member of the Project team and outline their role and responsibilities.

        If any project member is involved in other projects, please clearly state their commitment and how they avoid conflict of interest.

      9. Where are you right now in your roadmap? It's fully addressed.

      10. What is the business model of the Project? Share the dividends of transation fee by holding VX.

      11. What is the potential user base and market opportunity?

      Development

      1. What are the technological innovations of the project, if there are any?

      2. Where are your code repositories located?

      3. Do you have any products or UI demos can you share publicly? Are any built by your community, as opposed to being in-house demos?

      4. Do you plan to release weekly progress updates in this forum?

      5. Do you plan to host monthly or bi-monthly video AMAs?

      Funds

      1. Did you conduct any type of fundraising? When was it?

      2. How much in total did you raise?

      3. How much have you spent in total thus far? What have you spent these funds on?

      4. How much runway does your project require to ship the final product?

      5. What currency/coin/token do you plan to hold your funds in?

      6. What’s your coin storage/conversion policy? Do you only convert to fiat when you spend?

      7. How do you plan to publish your spending each month?

      8. Where are your funds stored? Please provide the addresses for public community tracking.

      Competitors

      1. Who do you view as your current competitors/peers? Binance DEX, IDEX

      2. What is your project’s competitive advantage over existing or potential future solutions? Feeless and fast transaction, trade date is recorded by blockchain.

      posted in Token Issuance & Listing
      A
      admin
    • RE: Introduction of ViteX Operator [XS_Fund]

      @鑫盛资本-无名 I have edit the style of your post for convenient reading.

      posted in Operator Introduction
      A
      admin