Can you give more details? About withdraw and deposit, please submit a ticket at here: https://vitex.zendesk.com/hc/en-001/requests/new
Posts made by admin
-
RE: Can't withdraw ETH
-
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
-
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.
-
RE: [ANN][PASC]PascalCoin: 1600TPS, POW, CPU, ASIC-resistance.
@Dzoelx Great project. The iOS wallet is only on the beta test?
-
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
-
RE: Introduction of ViteX Operator [Vite Online]
@ViteOnline Will you offer Gateway Services ? Please put the gateway info on the topic.
-
[ANN][VX]ViteX Coin: The native token of ViteX
Token Information & Economics
-
Token Name: ViteX Coin
-
Symbol: VX
-
Total Supply: 100,000,000
-
Circulating Supply: 0 (up to July 30,2019)
-
Operator: Vite Labs
-
Native Token on VITE: YES
-
Explorer: https://explorer.vite.net/
-
Token Allocation: 90% to community; 10% to Vite Labs
-
Please provide a list of team wallets that hold your token. N/A
-
Please provide all lockups in place for any holders of the token. N/A
-
Are you compliant in all jurisdictions that you service and operate in?
-
Please provide a detailed token migration plan. What mechanism will you be using? N/A
-
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.
-
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
-
Project Name: ViteX
-
Project Website: https://vitex.net/
-
White Paper: https://dex.vite.wiki/zh/dex/
-
Roadmap: (Share a link or image of your roadmap)
-
Link to your asset page on Vite network
-
A one-sentence pitch about your Project: ViteX is an Exchange by the community, of the community.
-
What are you planning to achieve with your project?
-
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.
-
Where are you right now in your roadmap? It's fully addressed.
-
What is the business model of the Project? Share the dividends of transation fee by holding VX.
-
What is the potential user base and market opportunity?
Development
-
What are the technological innovations of the project, if there are any?
-
Where are your code repositories located?
-
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?
-
Do you plan to release weekly progress updates in this forum?
-
Do you plan to host monthly or bi-monthly video AMAs?
Funds
-
Did you conduct any type of fundraising? When was it?
-
How much in total did you raise?
-
How much have you spent in total thus far? What have you spent these funds on?
-
How much runway does your project require to ship the final product?
-
What currency/coin/token do you plan to hold your funds in?
-
What’s your coin storage/conversion policy? Do you only convert to fiat when you spend?
-
How do you plan to publish your spending each month?
-
Where are your funds stored? Please provide the addresses for public community tracking.
Competitors
-
Who do you view as your current competitors/peers? Binance DEX, IDEX
-
What is your project’s competitive advantage over existing or potential future solutions? Feeless and fast transaction, trade date is recorded by blockchain.
-
-
RE: Introduction of ViteX Operator [XS_Fund]
@鑫盛资本-无名 I have edit the style of your post for convenient reading.
-
RE: Vite/Grin Beta Wallet Issue
@milkyklim said in Vite/Grin Beta Wallet Issue:
@Choeriswangqiji Thanks again. Swipe did the trick.
UPD: Tapping transaction doesn't work though – nothing happens.
It's not a bug. But it's our design problem. We will change it. Maybe tagpping transaction to show "cancel" and "copy" button is good.
-
RE: Vite Android Wallet APP is Online! (and Campaign of Reporting Bugs)
@felicity we have fixed it. Please check it again
-
RE: Full node synchronizing problems [v1.1.1]
What's going on this question? If it solved, pl mark this topic as resolved.
-
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.
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!
- a Supernode and/or SBP
- a builder of the Vite community and ecosystem internationally
- 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
-
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.
-
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
-
-
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:
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
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:
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:
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:
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:
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
-
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
- The DAG ledger structure of Vite
- The snapshot chain of Vite
The DAG Ledger Structure of Vite
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.
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,
- Initial state of the world: S1={A0=100, B0=100, C0=100}
- After account B transferred $20 to account A, state of the world : S2={A1=120, B1=80, C0=100}
- 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.
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.
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:
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.
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.
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.
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
The core code of the send transaction is as shown above:
- Construct a transaction and sign the transaction
- Pack the account status block and sign the packaged account status block
- Insert the account status block into the account chain and broadcast the block results
Receive Transaction
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.After the corresponding node receives the send transaction and passes the verification:
- Generate a received transaction and sign it
- Pack the account status block and sign the packaged account status block
- Insert the account status block into the account chain and broadcast the block structure
The Snapshotting Process of Snapshot Chain
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