Whitepaper and links:First Big TON project
Introducing FonoGram
FonoGram ecosystem
GRAM based utility token
WAVES based asset token
FonoGram TON Gate
FonoGram TON-based Exchange The FonoGram ecosystem is represented by the FonoGram automatic gate and the FonoGram Exchange. This system functions as an intermediate layer between the TON network and the user, allowing you to quickly exchange any cryptocurrencies for the GRAM token, and use the replenishment of your GRAM wallet in any way without additional verification.
The automatic gate FonoGram and the FonoGram exchange operate on the TON network, in a separate workchain and use our own FonoGram token for their operation.
Token FonoGram is utility token in the FonoGram workchain used to store data on trading operations and is an intermediate layer between the GRAM currency and our services. It is not visible to the end user (in any case, at the initial stage)
A FONOGRAM token based on the Waves platform is available for the user. This asset token, which is freely traded on various trading platforms, is the main asset in the FonoGram ecosystem and is technically connected with the token used in the TON network. Also, it is technically a FonoGram share, providing its holders with permanent dividends and giving them the opportunity to participate in the development of the eco-system.
Using a system of two connected tokens will provide our users with unprecedented security and usability. Our services will allow completely anonymously for the user to use the exchange of cryptocurrencies, replenishment with the fiat funds of the TON wallet, use all the services of the TON network.
FonoGram token distribution. In total, 2 million FonoGram tokens will be issued.
500,000 will be available to early investors, priced at $ 0.1 per token.
Further, after the launch of the primary token (on the Waves platform), three stages of sales are expected, with the parallel development of the declared services.
At each stage, we will put out 400,000 FonoGram tokens at a price of $ 0.5, $ 1 and $ 1.5.
200,000 tokens (10%) will be used for promotional campaigns and to support active communities.
100,000 remaining tokens will be used as an operational reserve.
The funds received will be used to develop the declared services and to maintain stable operation of all parts of the FonoGram ecosystem. Quarterly financial statements will be available to all our users.
Development time and methods.Why are we so confident in the possibility of developing the declared services and how long is the development?
We checked the functionality of the test GRAM wallet and got encouraging results. Already in the test environment, the necessary functions work fine. Accordingly, after the release of the release version, we only need to adapt the existing code to its realities. This will allow us to launch the declared services extremely quickly.
The full development period will be 6 months, plus about two weeks will be needed after the release of the TON network to adapt the existing code.
Technical reports will be available to our users every two months and contain general information on the development progress, examples of the components and part of the source code.
Roadmap. (Nearest plans) November 2019 - FonoGram announce. Presale program launch. Community Challenge launch.
December 2019 - Waves-based FonoGram token launch. Open trades on WavesDex. Community Challenge end. Airdrop for community.
February 2020 - First exchange-based sales stage. First technical report.
March 2020 - Second exchange-based sales stage. First financial report. Adding to additional major exchange.
April 2020 - Estimated launch date for TON network. Third exchange-based sales stage. Second technical report. Adding to additional major exchange.
May 2020 - Third technical report. Launch of the alpha version of the FonoGram Gate and FonoGram Exchange.
Technical partThe technical part of the FonoGram token based on the Gram cryptocurrency and is an integral part of the Gram blockchain, although it will be used in its own workchain.
We suggest learning about the TON network and the GRAM token in more detail with an analysis of basic concepts and basic features.
Basic concepts.
TL (Type Language). This is an abstract binary format for arbitrary data structures. It is used in the Telegram protocol and will be actively used in TON.
Hash (hash). A function that irreversibly converts an arbitrary data structure into a singular number of a fixed length. As part of the documentation, we are talking about the SHA-256 function.
Network node (node). A node is software that will ensure the operation of the system. In particular, it is assumed that each Telegram client application will include a TON node. At a low level, nodes have IPv4 / IPv6 addresses and communicate over UDP, at a higher level, they have abstract addresses and implement the ADNL protocol (for abstract addresses and ADNL, see below). When it comes to the fact that some parts of the system do something or store some data, it is understood that the network nodes do it.
An abstract address (or just an address). The node address is determined by its public key. More strictly, it is a 256-bit hash (SHA256) from the data structure containing the public key (the specific cryptographic algorithm is not specified in this case - elliptic curves and RSA-2048 are given as an example). So that one node can interact with another, it needs to know not only the address of that, but also this data structure. Theoretically, one physical node can create any number of addresses (corresponding to different keys).
Further, such a bunch is often used: a "prototype" in the form of a TL-structure (containing almost any data), and a 256-bit hash from it, used for addressing.
Blockchain is a data structure whose elements (blocks) are arranged in a "chain", and each subsequent block of the chain contains a hash of the previous one. In this way, integrity is achieved - changes can only be made by adding new blocks.
Service Services within TON can be of various types - depending on whether they use the blockchain or not. For example, one (or many) of the network nodes can process certain RPC requests using the ADNL protocol described below, without creating any entries in the blockchain - like traditional web servers. It also considers the possibility of implementing HTTP on top of ADNL, as well as the transition of the messenger itself to this protocol. Similar to TOR or I2P, this will make it more resistant to various locks.
At the same time, a number of services include interaction with the blockchain and processing requests outside it. For example, for TON Storage - file storage - it is not very reasonable to store the files themselves on the blockchain. It will contain only hashes of files (along with some meta-information about them), and specialized network nodes that are ready to give them to other nodes via ADNL will act as "file servers".
Fog service. We are talking about some services that involve decentralization and open participation in them. For example, TON Proxy is a service that any participant who wants to provide their site as an intermediary (proxy) forwarding packets between other nodes can support it. If desired, he can charge him the fee set by him - using the TON Payments system for micropayments (which, in turn, is also a foggy service).
TON Blockchain. This is the basis of the whole system. Nested into each other, virtually fragmented and even "vertical" blockchains inside blocks of other blockchains. And there will be some cool-sounding terms like Instant Hypercube Routing and Infinite Sharding Paradigm, but more on that later. And, of course, proof-of-stake and smart contracts.
TON P2P Network. A peer-to-peer network on the basis of which the system will be built. First of all, it will be discussed in this part of the story.
TON Storage. A file storage that, regardless of the blockchain, will be built on the aforementioned peer-to-peer network. You can compare with torrents.
TON Proxy. This is a service whose purpose is to increase the anonymity of network members. Any packet can be sent not directly, but through intermediary tunnels with additional encryption - like I2P or TOR.
TON DHT. Distributed hash table for storing arbitrary values. It is also built on top of the TON Network (but it is also used by it) and helps TON Storage to find the "distributing" nodes, and TON Proxy - intermediate relays. But it should be noted that, unlike the blockchain, this hash table is not a secure repository - important information cannot be stored in it.
TON Services. Platform for custom services. In fact - this is the new Internet on top of all of the above. Data exchange is through the TON Network / TON Proxy, and the logic is in the smart contracts of the TON Blockchain itself. And an interface with pretty familiar URLs.
TON DNS. Since we are talking about familiar URLs, we also need a converter from them to 256-bit addresses - accounts, contracts, services and nodes.
TON Payments. And only here the money issue is raised. And this will not only be a gram - as with ether, any "tokens" (including FonoGram) will be possible; GRAM here will be just the default currency.
DNL: Abstract Datagram Network Layer At the lowest level, the interaction between the nodes will be via UDP (although other options are acceptable).
As mentioned above, for one node to be able to send a packet to another, it must know one of its public keys (and therefore the address that it defines). He encrypts the packet with this key and adds the 256-bit recipient address to the beginning of the packet - since one node can have several such addresses, this will allow him to determine which key to use for decryption.
ADNL In addition, instead of the recipient address, the so-called channel identifier. In this case, the processing of the packet already depends on the specific agreements between the nodes - for example, the data sent to a channel can be destined for another node and must be forwarded to it (this is the TON Proxy service). Another special case may be the interaction directly between nodes, but with encryption on an individual key pair for this channel (pre-configured according to the Diffie-Hellman protocol).
Finally, the "zero" channel is a special case - if the node does not yet know the public keys of its "neighbors", it can send them packets without encryption at all. This is intended only for initialization - as soon as the nodes send information about their keys, they should be used for further interaction.
The above protocol (256 bit channel identifier + packet contents) is called ADNL. The documentation mentions the possibility of implementing a TCP analog on top of it or its own add-on - RLDP (Reliable Large Datagram Protocol), but does not go into details about their implementation.
TON DHT: Distributed Hash Table As with other distributed systems, TON involves the implementation of DHT, a distributed hash table. More specifically, the table is Kademlia-like. If you are not familiar with this kind of hash table - do not worry, then I will describe approximately how they are arranged.
DHT In an abstract sense, DHT associates 256-bit keys with some binary values of arbitrary length. At the same time, the keys in the table are the hashes of a specific TL structure (the structures themselves are also stored together with DHT). This is very similar to generating host addresses - and they can indeed be present in DHT (for example, the IP address of the host corresponding to the given abstract address can be located on such a key if it does not hide it). But in the general case, "prototypes of keys" (their descriptions, key descriptions) are metadata that indicate the "owner" of the entry in the hash table (that is, the public key of some node), the type of stored value and the rules by which this entry may change subsequently. For example, a rule may allow only the owner to change the value - or prohibit changing the value in a smaller direction (to protect against replay attacks).
In addition to 256-bit keys, the concept of DHT addresses is introduced. The difference with regular host addresses is that the DHT address is bound to an IP address. If the host does not hide its IP, it can use the normal address for DHT. But more often, for the needs of DHT, a separate, "semi-permanent" address will be started.
image
The notion of distance is introduced above the keys and DHT addresses - this all coincides with the Kademlia tables - the distance between the keys is equal to XOR (bitwise exclusive OR) from them. As in the Kademlia tables, the value corresponding to a certain key should be stored on s nodes having the smallest distance to this key (s here is a relatively small number).
In order for the DHT node to interact with other such nodes, it stores in memory the DHT routing table - the DHT and IP addresses of the nodes with which it interacted before, grouped by distance to them. There are 256 such groups (they correspond to the highest bit set in the distance value - that is, nodes at a distance from 0 to 255 will fall into one group, from 256 to 65535 - into the next, etc.). Within each group a limited number of "best" nodes are stored (in terms of ping to them).
TON DHT Structure Each node must support several operations: storing a value for a key, searching for nodes, and searching for values. The search for nodes implies issuing the given key to the nodes closest to it from the routing table; the search for values is the same, except for the situation when the node knows the value for the key (then it simply returns it). Accordingly, if a node wants to find a key value in DHT, it sends requests to a small number of nodes closest to this key from its routing table. If among their answers there is no sought value, but there are other addresses of nodes, then the request is repeated to them.
TON DHT can be used for various purposes, for example, to implement a torrent-like file storage (see TON Storage); to determine the addresses of nodes that implement certain services; to store information about account owners in the blockchain. But the most important application is the discovery of nodes by their abstract addresses.
For this, the address is used as the key whose value must be found. As a result of the request, either the host itself will be found (if the address sought was its semi-permanent DHT address), or the IP address and port for connection will turn out to be the value - or another address that should be used as an intermediary tunnel.
Overlay networks in TON
The ADNL protocol described above implies the ability of any nodes to exchange information with each other - however, not necessarily in optimal ways. We can say that thanks to ADNL, all nodes form a global graph TON (ideally, connected). But in addition, it is possible to create overlay networks - subgraphs inside this graph.
Overlay networks
Within such a network, interaction is carried out only directly - through pre-formed connections between nodes participating in the network (via ADNL channels described above). The formation of such connections between neighbors, the search for neighbors themselves is an automatic process that seeks to maintain the connectivity of the overlay network and minimize delays in exchanging data in it.
In addition, there is a way to quickly distribute large broadcast updates within the network - they are divided into parts, supplemented by an error correction code, and all these pieces are sent from one participant to another. Thus, the participant does not have to completely receive all the parts before sending them further on the network.
Overlay networks can be public and private. It is not difficult to become a member of a public network - you need to find a TL-structure that describes it (it can be public - or accessible by a certain key in DHT). In the case of a private network, this structure must be known to the node in advance.
Blockchain Content. Workchains.
Blockchain First of all, let's talk about what is planned to be stored on the blockchain. The status of accounts ("wallets" in the base case) and smart contracts (for simplicity, we assume that this is the same as the accounts) will be stored there. In fact, this will be a regular hash table - the keys in it will be the identifiers account_id, and the values will be data structures containing such things as:
balance;
smart contract code (only for smart contracts);
smart contract data storage (smart contracts only);
statistics;
(optional) public key for transfers from an account, by default account_id;
queue of outgoing messages (here they are entered for forwarding to the recipient);
A list of the most recent messages delivered to this account.
As mentioned above, the blocks themselves consist of transactions - messages delivered to various accounts account_id. However, in addition to account_id, messages also contain a 32-bit field workchain_id - the identifier of the so-called Workchain (workchain, working blockchain). This allows you to have several independent blockchains with different configurations. At the same time, workchain_id = 0 is considered a special case, a zero workchain - it is the balances that are in it that will correspond to the TON (Grams) cryptocurrency. Most likely, at the beginning of other workchains will not exist at all.
Shardchain. Infinite Sharding Paradigm. But this does not stop the growth in the number of blockchains. We will deal with sharding. Imagine that each account (account_id) has its own blockchain - it contains all the messages it receives - and the status of all such blockchains is stored on separate nodes.
Of course, this is very wasteful: most likely, each of these shardchains (shardchain, shard blockchain) will receive transactions very rarely, and there will be a lot of powerful nodes (looking ahead, I note that this is not just about clients on mobile phones - but about serious servers).
Therefore, shardchains combine accounts by binary prefixes of their identifiers: if the shardchain has the prefix 0110, then transactions of all account_id that start with these digits will fall into it. This shard_prefix can have a length of 0 to 60 bits - and most importantly, it can change dynamically.
Shardchain As soon as one of the shardchains receives too many transactions, the nodes working on it, according to predefined rules, "split" it into two children - their prefixes will be one bit longer (and for one of them this bit will be 0, and for the other - one). For example, shard_prefix = 0110b splits into 01100b and 01101b. In turn, if two "neighboring" shardchains start to feel quite freely (for some time), they will merge together again.
Thus, sharding is done "from the bottom up" - we assume that each account has its own shard, but for the time being they are "glued" by prefixes. This implies the Infinite Sharding Paradigm (paradigm of infinite sharding).I would like to emphasize separately that workchains exist only virtually - in fact, workchain_id is part of the identifier of a particular shardchain. In formal language, each shardchain is defined by a pair of numbers (workchain_id, shard_prefix).
Error correction. Vertical blockchains. It is traditionally believed that any transaction in the blockchain is "carved in stone". However, in the case of TON, it is possible to "rewrite history" - in case someone (the so-called "fisherman" node) proves that one of the blocks was signed incorrectly. In this case, a special correction block is added to the corresponding shardchain containing a hash of the corrected block (and not the last block in the shardchain). Representing the shardchain as a chain of blocks laid out horizontally, we can say that the corrective block is hooked to the erroneous block not to the right, but to the top - therefore, it is believed that it becomes part of a small "vertical blockchain". Thus, we can say that shardchains are two-dimensional blockchains.
Vertical blockchain If, after an erroneous block, subsequent blocks referred to the changes made by it (that is, new transactions were made on the basis of invalid ones), corrective blocks are also added to these blocks. If the blocks did not affect the "affected" information, these "corrective waves" do not apply to them. For example, in the illustration above, the transaction of the first block was recognized as incorrect, increasing the balance of account C - therefore, the transaction reducing the balance of this account in the third block should also be canceled, and an adjustment block will be closed over the block itself.
It should be noted - although the corrective blocks are depicted located "above" the original ones, in fact they will be added to the end of the corresponding blockchain (to where they should be chronologically). The two-dimensional arrangement only shows to which point in the blockchain they will be "hooked" (by means of the hash of the original block located in them).
Summary
An ecosystem based on the TON network allows us to offer our users an unprecedented level of convenience and security. Using a separate workchain in the TON network and the possibility of error correction, thanks to the vertical blockchain, will reduce the chance of losing money to a near-zero value.
The speed of transactions in the TON network and the ability to use additional services will provide users with maximum control of their money.
In general, exchange based on the FonoGram token located in the TON network can provide a good alternative to classic cryptocurrency exchanges, including decentralized ones
Community
COMMUNITY CHALLENGEWe believe that it is impossible to artificially create an active community. And developers can only support existing groups with relevant information and some funds. Therefore, we offer the following:
We will organize FonoGram token support for the most active communities in three areas:
- Social networks (Facebook, Twitter …)
- Specialized forums (Bitcoinalk, Bitcoinarden …)
- Information channels (Discord, Telegram)
Reward:10,000 tokens to the creator of the community and 35,000 tokens for distribution among members of the community.
Requirements:- Social network. At least 1000 subscribers. Use of our name to designate a community. The presence of live communication and the absence of artificially created accounts.
- Specialized forums. At least 40 relevant posts per day for a week from different accounts that are not artificially created.
- Information channels. At least 1000 subscribers. Use of our name to designate a community. The presence of live communication and the absence of artificially created accounts.
If you are ready to confirm these requirements, please send a link to your community by the specified e-mail. You will also need the data of the creator of the community (WAVES wallet number) to receive the award. ATTENTION! Verification of the information provided will be carried out.
Rewards will be issued at the time of the launch of thy FonoGram WAVES token.
Summary
An ecosystem based on the TON network allows us to offer our users an unprecedented level of convenience and security. Using a separate workchain in the TON network and the possibility of error correction, thanks to the vertical blockchain, will reduce the chance of losing money to a near-zero value.
The speed of transactions in the TON network and the ability to use additional services will provide users with maximum control of their money.
In general, exchange based on the FonoGram token located in the TON network can provide a good alternative to classic cryptocurrency exchanges, including decentralized ones.
LinksWebsite:
https://www.fonogram.siteCommunity acreditation mail:
community@fonogram.siteSales mail:
sales@fonogram.siteSupport mail:
support@fonogram.site
