diff --git a/Chapter 1/Lesson 2.md b/Chapter 1/Lesson 2.md index a781245..4a5ebc1 100644 --- a/Chapter 1/Lesson 2.md +++ b/Chapter 1/Lesson 2.md @@ -1,66 +1,95 @@ -# Chapter 1. Lesson 2. Blockchains, accounts, transactions in TON +# Blockchains, accounts, transactions in TON ###### tags: `Chapter 1` +## Blockchains and state transitions. +TON's blockchain serves as a ledger for state transitions. It's a ledger of changes in the state of arbitrary accounts. -## Blockchain accounts and transactions +> Every smart contract is also called an account. -In the previous lesson, we did an overview of the entire TON ecosystem. Now we're going to dive specifically into the architecture of the blockchain itself. +You should know the following things about **accounts**: +- has its own storage +- has its own unique address +- store the balance of Toncoins +- store the program code -### How blockchains work +##### Developers are provided with pretty much unlimited flexibility through the lifetime of the contract. +- They can change the data and they can even change the code of the contract +- They can transfer the coins around +- They can send messages to other contracts -So what is the block and what is the chain in the context of blockchain? TON blockchain is a ledger of state transitions. -It's kind of a more general idea than just a ledger of transfers. It's a ledger of changes in the state of arbitrary accounts. Every **smart contract** is also called an **account**. +However, there are justifiable limitations justified by the TON architecture: +> :eyes: Contracts have no visibility into anything outside themselves. By isolating contracts from each other, TON is infinitely scalable. -An account has its **own storage** and it has its own **unique address**. **Accounts** also stores **TON coins** balance and the **program code**. +> :globe_with_meridians: **TON smart contracts concept look very similar to computers on the internet**. In order to use some other contract state, the contract has to send an outgoing message and maybe later it will receive the desired reply. Like every computer is independent, they have their own data, they are programmed separately, and they have no idea when and how their messages will be processed by others. -It's up to the developer to design the logic of the contract by using any code they want within the syntax supported by the virtual machine called TVM. -Developers are provided with pretty much unlimited flexibility through the lifetime of a contract. They can change the data, they can even change the code of the contract in certain scenarios and of course - they can transfer the coins around. It's important to note that these contracts are self-contained, they have no visibility into anything outside themselves. This is what ensures the infinite scalability of the TON blockchain as every contract is isolated from the others - it can only receive the incoming message from some other contracts or from the outside world. The contract will then process this message by program code and change it's own state according to the results of this incoming message. +## Guarantees of blockchain. -As TON blockchain is asynchronous, it cannot go and read the state of any other contract and immediately get the result. In order to use some other contract's state, the contract has to send a message and maybe later, it will receive the desired reply. This concept makes those contracts look very similar to computers on the internet. So every computer is independent, they have their own data, their own programmed logic and they have no idea when and how their messages will be processed by others. +There are some *guarantees* that the blockchain provides to you as a developer. -### The Guarantees and Limitations of Blockchain Technology +> :white_check_mark: You could verify the address of any incoming message and be sure that behind this address, there is a specific code that you may trust. -There are some guarantees that the blockchain provides you as a developer. You could verify the address of any incoming message and be sure that behind this address there is specific code that you may trust. Similarly, if you send a message to a address, you have a cryptographic assurance that there will be specific code behind this address. The network guarantees that the message will be delivered but doesnt gauarantee how long this will take. The chain of messages could spend thousands of shards and take multiple blocks to finalize the transaction. +> :white_check_mark: The network guarantees the delivery of messages, but it doesn't guarantee how long this will take. -It may also be a case that some intermediate contracts run out of money and fail processing their messages, so when you develop the contract you need to focus on your own contract's consistency and the way it interacts with other contracts. +:x: The chain of messages could spend thousands of shards and take multiple blocks to finalize the transaction, so relying on a certain delivery time isn't really accurate. -### Messages and Transactions +## What are messages and what are transactions? -So what are messages and what are transactions. The thing that happens between the contracts is called a message, it carries a little bit of coins and arbitrary data to a contract address. -When the message arrives to the contract it's processed, the contract updated state, and emits new messages. All this activitity on a contract is recorded as a transaction. Think of this, if you have a chain of messages from contract A to contract B to contract C, then you have a message in between A and B. But you have transactions on A and transaction on B. And then if you have another message from B to C, that's the second message and the third transaction that is recorded on contract C. So if you have this chain with two messages, then you have three transactions and two messages. +> :envelope: *Message* - the things that happens in between two contracts. It carries a little bit of coins and arbitrary data to a contract address. -### The Process of Sending and Recording Transactions on the Blockchain -The blockchain itself is just a data structure. To change it, there must be a signal from the outside. The user presses a button in the wallet, the wallet creates an external message to a destination contract. The wallet sends this message to the validators who apply it to the contract. +> :gem: Transaction - activity on the contract including running contract code, updating contract state, and emitting new messages. -Most often, users send external messages to their own _wallet contracts_, which is their first transaction. Such messages contain embedded messages to other contracts. So the second transaction in the chain is a message from the wallet contract delivered and processed by the actual destination contract. -So you can see that every contract has its own transactions, which means that every contract has its own blockchain. And this is quite helpful, because the network can process and verify transactions independently from each other. The only question remains, how do you route these messages, and how do you prevent double spends? +## Every contract has its own little blockchain. -### Double Spends +The blockchain itself is just a data structure. To change it, there must be a signal from outside. -So let's start with double spends first. I can send money to, to person A, or I can send the money to person B, either of those are completely valid transactions. And from the perspective of the entire network it doesn't matter which one is recorded, as long as it is only one. And for this, we need consensus. To make consensus scale horizontally, TON uses proof of stake, where you have a set of validators that put the large amount of TON coins as a security deposit as a security bond, that guarantees that they don't misbehave. If any validator misbehaves or is switched off, they're punished with small or big fines that are taken out from this stick. +##### An example sequence of actions is roughly as follows: +1. User presses a button on the wallet. +2. The wallet creates an external message to a destination contract. +3. The wallet sends the message to the validators who apply it to the contract. -### TON's Scalable Validator Management and Sharding Mechanisms +> :exclamation: Every contract has its own transactions, which means that every contract has its own little blockchain. And this is quite helpful, because **the network can then process and verify transactions completely independently from each other**. -There are various mechanisms to prove to all the other validators whether this one was offline or misbehaving. Also in the setting, the set of validators can be shortened. If the load on the system increases, and a number of accounts grows, then the sets of validators could split in subgroups. For instance, even account numbers will be handled by one group and odd account numbers will be handled but by another. TON allows this sharding to be pretty much unlimited down to individual contracts depending on the load. +> :question: However, questions remain. How do we route these messages, and how do we prevent double spends? -### Two-Tier Blockchain System in TON for Transaction Processing +## Double-spending and consensus. -When all the validator groups achieve agreement on their parts of the blockchains, they record the state of the accounts on a central non-shardable blockchain called Masterchain where every validator participates. So in TON, you have this kind of two tier system, you have the master chain and you have the base chain. The base chain is the one that's kind of virtual because it actually contains all of these various accounts that could be sharded or can be immersed and split at any moment of time. In the master chain is this one non shardable chain that is expensive and not scalable, but also it's a very low load thing, it's only used to do the transactions on some configuration of the network. And the snapshots of all these sub chains from these validator groups. So that's kind of like the picture of the blockchain. And this kind of explains the latency in the transaction processing. So when you process a transaction on the blockchain, this takes around five to six seconds to be committed there, and then it takes another five to six seconds, for the same consensus kind of synchronization reason to commit this update in the master chain. +> :dollar: Double-spending - the expenditure of the same digital currency twice or more to avail the multiple services. -### Delays and Commitment Process in Global Transactions +Consensus prevents double spending by validators. *Proof-of-Stake* is used, with validators putting up security deposits. -So the total delay to make a globally visible commit of this transaction would take around 10 to 12 seconds. And this is just for the initial transaction, then if the transaction creates a long chain of messages, those could be routed, you know, over time, and eventually be committed in maybe the same or maybe different blocks. So if you're only interested in the final transaction, then that could take even longer. However, in typical scenarios, the chains of messages are quite short. Also, you often don't have to worry about committing the last one, because once the first transaction is recorded, you may often predict the results of all the subsequent transactions. For instance, when accepting simple payments with tokens, you may detect the confirmation of the initial transaction performed by the user and not worry about the funds arriving at your destination wallet, which may take four transactions. +> :gun: Misbehavior leads to *penalties*. -### Conclusion +> :paperclip: In TON, the set of validators can be **sharded**. -To conclude, in TON each contract is its own account with data and code. Contracts are isolated from each other and communicate by sending messages. This allows blockchain to be infinitely sharded. Consensus of validators guarantees that messages are eventually delivered, not replayed and funds are not double-spent. And finally, most operations take multiple transactions over a number of contracts, but it takes only seconds to confirm the very first transaction. +If the load on the system increases and the number of account grows, then the sets of validators could be split in subgroups. +TON allows **sharding** to be pretty much unlimited down to individual contracts, depending on the load. +## Two-tier blockchain system in TON +In TON we have two-tier system: +- We have **masterchain**. +- We have **basechain**. +When all the validator groups achieve agreement on their parts of the blockchain, they record the state of the accounts on a central non-shardable blockchain called **masterchain**, where every validator participates. +The basechain is *virtual*, because it actually contains all of these various accounts that could be sharded infinitely down to each individual account and could be split and merged into the **shardchains**. + +> :exclamation: Remember the following facts about masterchain! +> - It is **not shardable**. +> - It is **expensive in terms of fees**. +> - It **doesn't scale**. +> - It **contains only the configuration of the network and snapshots of all subchains from various validator groups**. + +## Transaction processing latency + +Committing transactions takes around 10 to 12 seconds (5-6 seconds to *basechain* and 5-6 seconds to *mastechain*), with chains of messages taking longer. Initial transactions predict subsequent results, reducing concern about confirming each step. + + +## Conclusion +In conclusion, TON employs a blockchain architecture where each contract is an isolated account with data and code. Consensus mechanisms prevent issues like double-spending. Despite some delays, transactions are confirmed relatively quickly.