Because taking cryptocurrencies mainstream in 2018 would not be possible using the
existing blockchain platforms,4 Telegram co-founder Dr. Nikolai Durov set out to find
a novel solution to meet the speed and scalability required for mass adoption.
At the core of the platform is the TON Blockchain — a scalable and flexible blockchain architecture that consists of a master chain and up to 2^92 accompanying blockchains.
TON blockchains can automatically split and merge to accommodate changes in load. This means that new blocks are always generated quickly and the absence of long queues helps keep transaction costs low, even if some of the services using the platform become massively popular.
TON blockchains use smart routing mechanisms to ensure that transactions between any two blockchains will always be processed swiftly, regardless of the size of the system. The time needed to pass information between TON blockchains grows logarithmically with their number, so scaling to even millions of chains will allow them all to communicate at top speed.
TON can «grow» new valid blocks on top of any blocks that were proven to be incorrect to
avoid unnecessary forks. This self-healing mechanism saves resources and guarantees that valid transactions will not be discarded due to unrelated errors.
TON uses a Proof-of-Stake approach in which processing nodes («validators») deposit stakes to guarantee their dependability and reach consensus through a variant of the Byzantine Fault Tolerant protocol. This allows TON to focus the computing power of its nodes on handling transactions and smart contracts, further increasing speed and efficiency.
The leaked link you shared is their “TON Primer”, which it says in fineprint on page 3 is just a “General Overview” of the proposed technology and its uses.
It mentions in the fineprint that there is another document called the “TON Technical Whitepaper”, which compares blockchains and describes in detail the “TON Protocol” and other Components such as the “TON Blockchain” and the “TON Infinite Sharding Paradigm”.
Has the “TON Technical Whitepaper” also been leaked? If so, where may we obtain a copy of it to help us understand how it works?
Mr. Durov needs to read about birthday paradox, his formulas make no sense, and also why so much obsession about numbers ?)) Why 10^{-18} ? May because it is a billion of billions and Mr. Durov thinks it is a really really big number ?))
Fixing an incorrectblock generates “ripples” that are ultimately propagated towards the recent blocks of all affected shardchains; these changes are reflected in new“vertical” masterchain blocks as well
Seem to be lots of ripples - this essentially breaks all existing mathematical proofs of bllockchain security so it is a totally unchartered territory ruled by the genius of Mr. Durov
Most systems would achieve this by “rolling back” to the last block before the invalid one in this shard chain and the last blocks unaffected by messages propagated from the invalid block in each of the other shard chains, and creating a new fork from these blocks. This approach has the disadvantage that a large number of otherwise correct and committed transactions are suddenly rolled back, and it is unclear whether they will be included later at all
Which “most systems”? Who would design a crazy system that “suddenly rolls back” committed transactions?))
TVM offers support for bit strings and byte strings
If it supports bit strings isnt it automatically supposed to support byte strings, because a byte string is also a bit string ?)))
Once a validator obtains enough chunks to reconstruct the block candidate from them, it signs a confirmation receipt and propagates it through its neighbors to the whole of the group. Then its neighbors stop sending new chunks to it, but may continue to send the(original) signatures of these chunks, believing that this node can generate the subsequent chunks by applying the Reed–Solomon or fountain code by itself(having all data necessary), combine them with signatures, and propagate to its neighbors that are not yet ready
This is like the worst BFT protocol ever created ) How can neighbors “believe” in something - are they some kind of live creatures ? Or Mr Durov wants to put a human on each node ?))
How can neighbors know which other neighbors are ready and which are not ready? And then ready for what ?) He never explains what should they be ready for.
I can not say whats wrong about it since I dont understand it, the entire paper is written in a random random style And since I am a really nice kind guy and usually try hard to understand things, I can conclude that the paper is badly written, and, therefore, the author is mediocre, since talented people write good papers ) And then since he is a mediocre guy, the entire statement Telegram makes about superiority of their things is really a sick, sick thing.
When people really invent something new, they are usually able to explain this in simple, clear terms. Einstein’s thesis was just two pages, he got a Nobel Prize for it
Those are not technical comments by any means. It would be interesting to actually know what community thinks about the proposed solution (or lack of )…
s = {0...255}. The entire thing falls apart when you realize its a hash function on a single byte. It’s almost guaranteed there will be at least one collision when you map a single byte to single byte (check out the Birthday Paradox if this doesn’t make sense to you).
I think the author says you can fix that by extending the output of the hash function to be k-bits long to produce a collision chance of 2^-k. At that point you might as well make the hash function f(x) -> x since its operating on a single byte and produces a larger output than input in a deterministic fashion. (8) is not a useful conclusion because it doesn’t ask for the probability that Hash(s) will clash with Hash(s') but if it will clash with just one certain Hash(s').
As far as I can see there is a proposal to use trustless payment channels. The idea is to create “money pools” and let users to make transactions without use of blockchain every time.
I do not understand how there can be a project like this with so many ‘loopholes’ … more recent projects like FLETA Blockchain have already achieved with sharding parallel and multichains to solve the scalability with 15k TPS
And since I am a really nice kind guy and usually try hard to understand things, I can conclude that the paper is badly written, and, therefore, the author is mediocre, since talented people write good papers ) And then since he is a mediocre guy, the entire statement Telegram makes about superiority of their things is really a sick, sick thing.