Source on GitHub

Smart Contract Address


Testing and Issues

You can test this entry and submit issues during the testing period of the Blockchain Contest, Stage 2 contest.

Entries with serious issues will not be able to win the contest, but even minor issues might be important for overall results.




Interact *directly with the TON blockchain* with no middlemans, directly from your browser!

This is possible thanks to a client-side implementation of the ADNL P2P protocol.
Connection to the liteservers is made through a simple websocket proxy that simply acts as a TCP <=> websocket proxy.

*All cryptography is done exclusively in the browser, allowing fully secure interaction with the chosen TON node*.

TL, ECC w/ TON ADNL, BOC deserialization is implemented.

Initially, I intended to submit an OUTPACE-inspired ad network controlled by the TON blockchain.
I initially decided to develop a custom TON workchain for the needs of my ad network, but then realized that I first needed a way to interact with the TON network, first, which is why I developed this pure-JS TON lite-client.

I also initially intended to create also a very basic ad network smart contract, but then decided to focus all efforts on finishing this library, first.
You have not added any comments yet...
by rating


Looks good, thank you
Great job done, please do not stop!
Magic Python Dec 26, 2019 at 15:07
Wow, quite ambitious targets. I hope you had some fun working on it.

I will try to summarize what, in my opinion, is already implemented and how important/challenging it is.
Feel free to correct me.

1. The protocol used by AdnlExtClient is ported to javascript. It is a quite simple protocol over TCP, which is used mostly for lite-client <--> lite-server interactions. For this purpose alone, could be a better match. Some proxy is necessary anyway (WebSocket in your case).
I should note that this is NOT protocol for interaction with ADNL network itself. So "P2P" used in the description is a bit confusing.
Still, it is useful to have such implementation in js (or even php, huh?) in some cases.

2. TL (not TLB) serialization/deserialization. It is necessary to interact with lite-server.
I should note that (in my opinion) TLB is much more complicated than TL, especially when compared to the simplified version of TL, which is actually used.

3. Deserialization of Bag of Cells
To interpret results received from lite-server, one should be able to work with a bag of cells. It is partially implemented.
Also, no validation is supported. A proper lite-client would be able to validate all proofs from lite-server. Currently it
is impossible even to calculate a hash of a cell.
But in a lot of cases, such strict validation is not necessary. One could just trust a lite-server.

4. Cryptography primitives.
These primitives would be useful in the next stages too.

What is left (tlb, fift and tvm) would require much more work.
But what is done is quite impressive and useful.
Classy Bee Dec 27, 2019 at 22:42
Indeed I had (& am having) a lot of fun working on this project.

1. Yeah I confused the naming, changed that bit.

2. Indeed I haven't implemented TL-B deserialization yet, I am currently working on a static JS TL-B parser.

3. I will improve my implementation of BOC after finishing the TL-B parser.
I am aware that I've yet to implement merkle tree validation to validate received blocks, I will implement that (possibly after finishing a basic fift interpreter, to allow execution of pre-existing fift software).

4. Yep, I already implemented mixed edwards/montgomery curve primitives for the liteserver handshake using a patched version of tweetnacl, I only have to integrate them in TVM/fift.

Thank you for your words, I will continue working on the library, as I know it can be very useful to the TON community.
I am really looking forward to implementing FIFT and TVM, too, should be a lot of fun.

Have a wonderful New Year!
فیروزه رمضان زاده (Nordstrom ) Jan 17, 2020 at 12:54
Happy new year
Classy Bee Mar 1, 2020 at 22:56
Nobody added any issues yet...