TON technical overview

2020-03-12 09:59:48 @tolyayanot and me are presenting js library TonWeb https://github.com/toncenter/tonweb

TonWeb mimic ethereum's Web3 for easy migration.

What can it do for now:
* Work with contract like it is a simple js-object. There is also predefined set of wallet contracts, interface supports deploy, send, estimate fees and get methods.
* Get contracts info from blockchain: data, code and balance. Get transactions history
* Provide utilities for work with addresses, converting grams etc
* Low-level serialization of BoCs. Cell, bitstring and messages objects are included.
* Work with mnemonic phrases.

Our wallet, gram-wallet.org now works on TonWeb. Open / Comment

2020-02-19 12:29:17 I managed to launch private TON-testnets, thanks to @akhme & @hortonelectric. Packed all scripts to docker-container:
https://github.com/EmelyanenkoK/ton-private-network
docker pull kaemel/ton-private-net
Validation will start in 2 minutes after running of the container.
With corresponding flags, node works as liteserver and is ready for deployment of contracts including system ones: config, elector and minter.
For now, network work only with one chain (without basechain). Open / Comment

2020-02-10 14:22:59 Recently, I found quite interesting bug in the node code (it has already been fixed). TVM can effectively create and handle objects with high nesting levels. However, serializing such objects into a text representation can take "infinitely" much space.
Here, for example, is the code that generates tuples with a high nesting level (it costs approximately 180 gas per iteration):

(tuple) wrap2tuples (tuple x, tuple y) asm "PAIR";
(tuple) empty_tuple () asm "PUSHNULL";
(tuple) tuple_bomb(int level) {
int current_level = 0;
var bomb = empty_tuple();
do {
current_level += 1;
bomb = wrap2tuples(bomb, bomb);
} until (current_level > level );
return bomb;
}

Accordingly, if we generate a tuple with a nesting level of, lets say, 100 and can force the node to transfer it over the network or write to disk in serialized form, the node will crash. Note, that in a non-serialized representation this tuple requires only 101 objects to be stored, since although there are 2**100 leaves in the tuple, all these leaves are the same.

One of the case where this bug could crash a node is the usage of runmethodx, a special light server method that allows you to run the contract's get-method on a light server and receive only the result with proofs on the client (this is useful when the contract has too much storage to transfer all of it to the client and execute get methods locally). If you generate a contract, with get-method which returns a tuple with a high nesting level , then the light server will crash in an attempt to allocate memory for storing the result of the method. I want to thank guys from Everstake.one (they are staking grams and have a pretty cool system for monitoring the node behavior ) for helping me in testing this bug.

Another way to use this bug is based on the fact that by default, debug opcodes in the node were not disabled and debug was written directly to stder at any verbosity level. When I discovered this, @Skydev immediately suggested spamming the logs with debug https://github.com/ton-blockchain/ton/issues/246 . This method works and may clog the entire disk over time, however, dumping a nested tuple is much more efficient: a single call with a sufficient nesting level can eat any disk. Open / Comment

2020-02-06 23:42:15 In the last commit 77842f9b TON developers added a proxy server running on top of the transport layer of the TON nodes network.
Also, new opcodes that recursively calculate the cell size were added. The fee for reading cells has been changed: re-reading will cost 25 gas, first access still 100. Wallet versioning was introduced. I want to congratulate our colleague, @Skydev : his manual-DNS contract, which won the smart contract contest, was added to the smart contract collection.
Tonlib API was slightly changed: now it will be possible to request the status of contracts at the certain block + it will be possible to work with wallets of different versions. Open / Comment

2020-01-22 00:37:00 Meet the web version of the TON wallet gram-wallet.org
Yanot @tolyayanot and I developed a browser version of TON wallet that is fully compatible with the official one.
All cryptography, of course, is client-side (private keys do not leave your device), the keys are stored in the browser memory, encrypted with a password that is entered during transaction generation. The version is specially optimized for mobile devices, it is convenient to open it directly from the telegram. A nice bonus is that, unlike official wallets, it weighs a little bit less than 100mb Open / Comment

2019-12-28 20:21:57 Viewst Creative Ad Builder viewst.com (with me as the developer) released pyTON: python wrapper for tonlibjson. https://github.com/viewst/pyTON
There are functions for getting account states, transactions, sending messages to blockchain, and running getmethods.
Also, there is embedded webserver, and now you can run your own local analog ton.sh or toncenter.com via two commands:
pip3 install pyTON && python3 -m pyTON
(python 3.7+ is required)
While we keep web server API close to presented on ton.sh, our service is more functional. For instance, there are no limits for requested transactions, and it is possible to request all transactions which happened after the known one. Also, you may send BOC's to network both as serialized cell and in object format: {"data": {"b64": "...", "len": int }, "refs": [...subcells...]}. It is also possible to turn on API for running getMethods (although we do not recommend to open this API for public servers since it is possible to crash liteclient by maliciously constructed getMethod). Open / Comment

2019-12-14 17:25:26 In recent updates, new opcodes have been added for working with RNG and libraries:
RAND, RANDU256, ADDRAND, SETRAND, SETLIBCODE, CHANGELIB
(thanks @akhme for noticing) Open / Comment

2019-11-10 15:42:25 One of the most exciting TON usecases, is the opportunity to create a token working on external messages. How it is supposed to work?
There are users with their balances and there are gas providers, people who are willing to pay transfer fees in grams in exchange for a commission in tokens. Users send an external message transfer, choose a gas provider with the best price and pay a commission to him.
That way, the user should not bother that in order to send his "shiny tokens" he needs to first top up his account by grams and make sure that the balance is greater than a certain limit. He may not even know that the token works on TON. Got a public key? Tokens can be sent to it (without any preliminary preparation). Are there enough tokens on the account of the corresponding key? You can immediately send them without worrying about buying grams.
This is a killer-feature, which, coupled with a huge user base, would instantly transfer to TON points of brand loyalty, airline miles, tokenize in-game resources, etc.
Unfortunately, it seems that low gas-credit and growth of the cost of working with dictionaries as the dictionary grows, kills this idea.
In this repository, https://github.com/EmelyanenkoK/TON_tokens is the result of a couple of weeks of reflection and several days of work on that kind of token. Yesterday and today I spent some time on optimization (thanks @akifoq for help), but I did not achieve stunning results.
If the balance sheet is empty, all checks which should be done before accept_message fit within the limit of 10k gas credit, but when number of users grows to a thousand, the first attempt to find the sender balance in the dictionary overflows. It should be noted that the cost of searching in the dictionary grows logarithmically with the size of the dictionary, so that problem can, in principle, be mitigated.
For instance, increase of gas credit to 50k already allows to work with 100k users. Another way is a substantial (for example 20x) discount for non-changing reading from dictionaries.
Finally, the possibility of optimizing the token code is probably not exhausted yet.
P.S. I will be glad to see pool requests with optimizations, you can test the correct work of the token using the script test_external.fif, also you can test the operation of the token with a large balance dictionary using script test_external_highload.fif Open / Comment

2019-11-01 10:36:47 Source code for wallet-apps for android, ios and desktop (win, mac, lin) was released. Desktop wallets can be downloaded on official site wallet.ton.org .
Besides, there was released a new 3rd version of the wallet-smart contract. It works the same way as the first and the second but allows us to deploy many wallets with different addresses and the same public key. In new config-code.fc (it is one of the government contracts) traces of an ability to suggest new features and vote for them have appeared (it is not finished, though). Open / Comment