diff --git a/README.md b/README.md index d4b39686..60fd84b1 100644 --- a/README.md +++ b/README.md @@ -16,13 +16,45 @@ Proposal management is done using GitHub pull requests, the process is described ## Merged TEPs ## Active -| TEP | Title | Type | Created | -|--------------------------------------------|----------------------------------|------------------|-----------| -| [1](./text/0001-tep-lifecycle.md) | TEP Lifecycle | Meta | 11.06.2022| -| [62](./text/0062-nft-standard.md) | NFT Standard |Contract Interface| 01.02.2022| -| [64](./text/0064-token-data-standard.md) | Token Data Standard |Contract Interface| 03.02.2022| -| [66](./text/0066-nft-royalty-standard.md) | NFTRoyalty Standard Extension |Contract Interface| 12.02.2022| -| [74](./text/0074-jettons-standard.md) |Fungible tokens (Jettons) standard|Contract Interface| 12.03.2022| -| [81](./text/0081-dns-standard.md) | TON DNS Standard |Contract Interface| 25.06.2022| -| [85](./text/0085-sbt-standard.md) | SBT Contract |Contract Interface| 09.08.2022| -|[89](./text/0089-jetton-wallet-discovery.md)| Discoverable Jettons Wallets |Contract Interface|08.09.2022 | +| TEP | Title | Type | Created | +|----------------------------------------------|------------------------------------|--------------------|------------| +| [1](./text/0001-tep-lifecycle.md) | TEP Lifecycle | Meta | 11.06.2022 | +| [2](./text/0002-address.md) | TON Addresses | Core | 07.09.2019 | +| [62](./text/0062-nft-standard.md) | NFT Standard | Contract Interface | 01.02.2022 | +| [64](./text/0064-token-data-standard.md) | Token Data Standard | Contract Interface | 03.02.2022 | +| [66](./text/0066-nft-royalty-standard.md) | NFTRoyalty Standard Extension | Contract Interface | 12.02.2022 | +| [74](./text/0074-jettons-standard.md) | Fungible tokens (Jettons) standard | Contract Interface | 12.03.2022 | +| [81](./text/0081-dns-standard.md) | TON DNS Standard | Contract Interface | 25.06.2022 | +| [85](./text/0085-sbt-standard.md) | SBT Contract | Contract Interface | 09.08.2022 | +| [89](./text/0089-jetton-wallet-discovery.md) | Discoverable Jettons Wallets | Contract Interface | 08.09.2022 | +| [115](./text/0115-ton-connect.md) | TON Connect | Core | 20.10.2022 | +| [160](./text/0160-dispatch-queue.md) | Dispatch Queue | Core | 13.06.2024 | + + +## WIP +Since standard truly become a _Standard_ not when it gets merged into this repository, but when multiple parties accept it and use to interact with each other, below we list proposals to which developers may refer in documentation and so on. +In particular "Status" below has the following sense: +* "Proposed" - this standard hasn't implementation or implementation is used only by authors +* "Partially Deployed" - this standard is used by pair of actors (for instance one dApp and one wallet, or similar), but not by interconnected set of actors +* "Deployed" - this standard is used by multiple actors (and generally should be on the way of merging) + +| TEP | Title | Type | Created | Status | +|----------------------------------------------|------------------------------------|--------------------|------------|------------| +| [91](https://github.com/ton-blockchain/TEPs/pull/91/files) | Contract Source Registry | Infrastructure | 09.09.2022 | ✅Deployed✅ | +| [92](https://github.com/ton-blockchain/TEPs/pull/92/files) | Wallet Registry | Infrastructure | 11.09.2022 | Proposed | +| [96](https://github.com/ton-blockchain/TEPs/pull/96/files) | Dicts/Arrays in Metadata | Contract Interface | 21.09.2022 | Proposed | +| [104](https://github.com/ton-blockchain/TEPs/pull/104/files) | Data Signatures | Contract Interface | 13.12.2022 | Proposed | +| [121](https://github.com/ton-blockchain/TEPs/pull/121/files) | Lockable Jetton Wallet | Contract Interface | 13.04.2023 | Proposed | +| [122](https://github.com/ton-blockchain/TEPs/pull/122/files) | Onchain reveal mechanic | Contract Interface | 31.10.2022 | ✅Deployed✅ | +| [123](https://github.com/ton-blockchain/TEPs/pull/123/files) | Address Guideline update | Guidelines | 13.06.2023 | 🛠️Partially Deployed🛠️ | +| [126](https://github.com/ton-blockchain/TEPs/pull/126/files) | Compressed NFT Standard | Contract Interface | 28.07.2023 | 🛠️Partially Deployed🛠️ | +| [127](https://github.com/ton-blockchain/TEPs/pull/127/files) | TON Storage in Metadata | Contract Interface | 23.09.2023 | Proposed | +| [130](https://github.com/ton-blockchain/TEPs/pull/130/files) | Rebase Jettons standart | Contract Interface | 04.12.2023 | Proposed | +| [131](https://github.com/ton-blockchain/TEPs/pull/131/files) | Referral code in Query ID | Contract Interface | 26.12.2023 | 🛠️Partially Deployed🛠️ | +| [137](https://github.com/ton-blockchain/TEPs/pull/137/files) | Jetton Wallet Balance Query | Contract Interface | 09.01.2024 | Proposed | +| [140](https://github.com/ton-blockchain/TEPs/pull/140/files) | Programmable Action Phase | Core | 20.01.2024 | Proposed | +| [141](https://github.com/ton-blockchain/TEPs/pull/141) | Remote onchain execution | Core | 20.01.2024 | Proposed | +| [142](https://github.com/ton-blockchain/TEPs/pull/142/files) | TBRC-20 Inscription Token Standard | Contract Interface | 26.01.2024 | Proposed | +| [145](https://github.com/ton-blockchain/TEPs/pull/145/files) | Metadata "Hidden" render type | Contract Interface | 26.01.2024 | ✅Deployed✅ | +| [146](https://github.com/ton-blockchain/TEPs/pull/146/files) | Semi-fungible token standard | Contract Interface | 17.03.2024 | Proposed | +| [161](https://github.com/ton-blockchain/TEPs/pull/161/files) | Proxy TON (wTON) | Contract Interface | 13.06.2024 | 🛠️Partially Deployed🛠️ | diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 00000000..b7a2292c --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,21 @@ +# Security Policy + +## Supported Versions + +Use this section to tell people about which versions of your project are +currently being supported with security updates. + +| Version | Supported | +| ------- | ------------------ | +| 5.1.x | :white_check_mark: | +| 4.0.x | :x: | +| 4.0.x | :white_check_mark: | +| 5.0 x | :x: | + +## Reporting a Vulnerability + +Use this section to tell people how to report a vulnerability. + +Tell them where to go, how often they can expect to get an update on a +reported vulnerability, what to expect if the vulnerability is accepted or +declined, etc. diff --git a/text/0002-address.md b/text/0002-address.md new file mode 100644 index 00000000..57d696e6 --- /dev/null +++ b/text/0002-address.md @@ -0,0 +1,132 @@ +- **TEP**: [2](https://github.com/ton-blockchain/TEPs/pull/2) +- **title**: TON Addresses +- **status**: Active +- **type**: Core +- **authors**: - +- **created**: 07.09.2019 +- **replaces**: - +- **replaced by**: - + +# Summary + +This document describes TON addresses and their representation. + +# Specification + +## Smart-contract addresses + +Smart-contract addresses in the TON Network consist of two parts: + +(a) the workchain ID (a signed 32-bit integer) and + +(b) the address inside the workchain (64-512 bits depending on the workchain). + +Currently, only the masterchain (workchain_id=-1) and the basic workchain (workchain_id=0) are running in the TON Blockchain Network. Both of them have 256-bit addresses, so until a new different workchains appears we assume that workchain_id is either 0 or -1 and that the address inside the workchain is exactly 256-bit. + +Under the conditions stated above, the smart-contract address can be represented in the following forms: + +A) "Raw": :<64 hexadecimal digits with address> + +B) "User-friendly", which is obtained by first generating: +- one tag byte (0x11 for "bounceable" addresses, 0x51 for "non-bounceable"; add +0x80 if the address should not be accepted by software running in the mainnet network) +- one byte containing a signed 8-bit integer with the workchain_id (0x00 for the basic workchain, 0xff for the masterchain) +- 32 bytes containing 256 bits of the smart-contract address inside the workchain (big-endian) +- 2 bytes containing CRC16-CCITT of the previous 34 bytes + +In case B), the 36 bytes thus obtained are then encoded using base64 (i.e., with digits, upper- and lowercase Latin letters, '/' and '+') or base64url (with '_' and '-' instead of '/' and '+'), yielding 48 printable non-space characters. + +Example: + +The "root dns" (a special smart contract residing in the masterchain) has the address + +`-1:e56754f83426f69b09267bd876ac97c44821345b7e266bd956a7bfbfb98df35c` + +in the "raw" form (notice that uppercase Latin letters 'A'..'F' may be used instead of 'a'..'f') + +and + +`Ef_lZ1T4NCb2mwkme9h2rJfESCE0W34ma9lWp7-_uY3zXDvq` (bounceable) + +`Uf_lZ1T4NCb2mwkme9h2rJfESCE0W34ma9lWp7-_uY3zXGYv` (non-bounceable) + +in the "user-friendly" form (to be displayed by user-friendly clients). + +Notice that both forms (base64 and base64url) are valid and must be accepted. + +## Wallets applications + +At the moment, TON wallets work with addresses as follows: + +For receiving: + +- Wallets display the user's address in a user-friendly bounceable or non-bounceable form (at the moment, the majority of wallet apps display bounceable form). + +When sending: + +1) The wallet app checks the validity of the destination address representation - its length, valid characters, prefix and checksum. If the address is not valid, then an alert is shown and the sending operation is not performed. + +2) If the address has a testnet flag, and the wallet app works with the mainnet network, then an alert is shown and the sending operation is not performed. + +3) The wallet app retrieve from address bounceable flag. + +4) The wallet app check the destination address - if it has `unitialized` state wallet force set `bounce` field of sending message to `false` and ignore bounceable/non-bounceable flag from address representation. + +5) If destination is not `unitialized` then wallet app uses the bounceable/non-bounceable flag from the address representation for the `bounce` field of sending message. + +## Public keys + +The ubiquitous 256-bit Ed25519 public keys can be represented in the following forms: + +A) "Raw": <64 hexadecimal digits with address> + +B) "User-friendly" or "armored", which is obtained by first generating: + +- one tag byte 0x3E, meaning that this is a public key +- one tag byte 0xE6, meaning that this is a Ed25519 public key +- 32 bytes containing the standard binary representation of the Ed25519 public key +- 2 bytes containing the big-endian representation of CRC16-CCITT of the previous 34 bytes. + +The resulting 36-byte sequence is converted into a 48-character base64 or base64url string in the standard fashion. + +For example, the Ed25519 public key `E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D` (usually represented by a sequence of 32 bytes `0xE3, 0x9E, ..., 0x7D`) has the following "armored" representation: + +`Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2` + +## ADNL address + +The ADNL protocol based on 256-bit abstract addresses. + +The ADNL address can be represented in the following forms: + +A) "Raw": <64 hexadecimal digits with address> + +B) "User-friendly" or "armored", which is obtained by first generating: + +- one tag byte 0x2d, meaning that this is a ADNL address +- 32 bytes containing 256 bits of the ADNL address (big-endian) +- 2 bytes containing the big-endian representation of CRC16-CCITT of the previous 34 bytes. + +The resulting 35-byte sequence is converted into a 55-character base32 string in the standard fashion. + +Example: + +For example ADNL address `45061C1D4EC44A937D0318589E13C73D151D1CEF5D3C0E53AFBCF56A6C2FE2BD` has the following "armored" representation: + +`vcqmha5j3ceve35ammfrhqty46rkhi455otydstv66pk2tmf7rl25f3` + +# Drawbacks + +- It is impossible to extract the public key from the address, which is needed for some tasks (for example, to send an encrypted message to this address). + Thus, until the smart contract is deployed for this address, there is no way to get the public key on-chain. + +- (UI) Most OS do not allow you to select an address with double click because of '_', '-', '/', '+' base64 symbols. + +# Rationale and alternatives + +- The prefix (the first byte(s)) allows you to understand exactly what type this address or key is. + +- The checksum built into the address prevents the loss of funds due to a user typo. + +- Built-in testnet flag prevents loss of funds by a user who mistakenly tries to send real coins to a testnet address. + +- A different form of address than most other blockchains allows the user to more easily identify the TON address. \ No newline at end of file diff --git a/text/0064-token-data-standard.md b/text/0064-token-data-standard.md index 623ea879..94f91011 100644 --- a/text/0064-token-data-standard.md +++ b/text/0064-token-data-standard.md @@ -82,6 +82,7 @@ Three options can be used: Data encoded as described in "2. On-chain content layout". The dictionary must have `uri` key with a value containing the URI pointing to the JSON document with token metadata. Clients in this case should merge the keys of the on-chain dictionary and off-chain JSON doc. + In case of collisions (the field exists in both off-chain data and on-chain data), on-chain values are used. ## Data serialization Data that does not fit in one cell can be stored in two ways: @@ -107,9 +108,9 @@ If the prefix is not `0x00` or `0x01`, then the data is probably encoded by the ## Informal TL-B scheme: ``` text#_ {n:#} data:(SnakeData ~n) = Text; -snake#00 data:(SnakeData ~n) = ContentData; +snake#00 {n:#} data:(SnakeData ~n) = ContentData; chunks#01 data:ChunkedData = ContentData; -onchain#00 data:(HashMapE 256 ^ContentData) = FullContent; +onchain#00 data:(HashmapE 256 ^ContentData) = FullContent; offchain#01 uri:Text = FullContent; ``` @@ -171,3 +172,5 @@ None * 31 Aug 2022 - added note about data encoded in TL-B schema in "Data serialization" paragraph. * 14 Oct 2022 - render_type and amount_style for Jetton metadata + +* 20 Dec 2023 - added clarification for semi-chain data: "In case of collisions (the field exists in both off-chain data and on-chain data), on-chain values are used." diff --git a/text/0066-nft-royalty-standard.md b/text/0066-nft-royalty-standard.md index 6a8dd54e..eeaa8210 100644 --- a/text/0066-nft-royalty-standard.md +++ b/text/0066-nft-royalty-standard.md @@ -58,7 +58,7 @@ NFT Collection smart contract MUST implement: Send back message with the following layout and send-mode `64` (return msg amount except gas fees): TL-B schema `report_royalty_params#a8cb00ad query_id:uint64 numerator:uint16 denominator:uint16 destination:MsgAddress = InternalMsgBody;` -It is expected that marketplaces which want to participate in royalty payments will send `muldiv(price, nominator, denominator)` to `destination` address after NFT sale. +It is expected that marketplaces which want to participate in royalty payments will send `muldiv(price, numerator, denominator)` to `destination` address after NFT sale. Marketplaces SHOULD neglect zero-value royalty payments. diff --git a/text/0074-jettons-standard.md b/text/0074-jettons-standard.md index 16f540db..42b53d44 100644 --- a/text/0074-jettons-standard.md +++ b/text/0074-jettons-standard.md @@ -25,7 +25,7 @@ Jetton standard describes: ## Useful links 1. [Reference jetton implementation](https://github.com/ton-blockchain/token-contract/) 2. [Jetton deployer](https://jetton.live/) -3. FunC Jetton lesson ([en](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/9lesson/ninthlesson.md)/[ru](https://github.com/romanovichim/TonFunClessons_ru/blob/main/9lesson/ninthlesson.md)) +3. FunC Jetton lesson ([en](https://github.com/romanovichim/TonFunClessons_Eng/blob/main/lessons/smartcontract/9lesson/ninthlesson.md)/[ru](https://github.com/romanovichim/TonFunClessons_ru/blob/main/lessons/smartcontract/9lesson/ninthlesson.md)) # Specification diff --git a/text/0081-dns-standard.md b/text/0081-dns-standard.md index 69a03e33..d6b623e7 100644 --- a/text/0081-dns-standard.md +++ b/text/0081-dns-standard.md @@ -23,7 +23,7 @@ to be used by default whenever an application or a service wants to translate hu 1. [Reference DNS smart contracts](https://github.com/ton-blockchain/dns-contract) 2. [DNS Auction](https://dns.ton.org/) ([source code](https://github.com/ton-blockchain/dns)) 3. [ton.org documentation](https://ton.org/docs/#/web3/dns) -4. Tolya answers about TON DNS (ru) - [1](https://github.com/ton-blockchain/TEPs/commit/4a09bfc737823f09f05dfb7008eec7784543bb2b), [2](https://telegra.ph/Otvety-na-voprosy-o-TON-DNS-kanalu-Investment-kingyru-CHast-2-08-06), [3](https://telegra.ph/Otvety-na-voprosy-o-TON-DNS-kanalu-Investment-kingyru-CHast-3-08-09) +4. Tolya answers about TON DNS (ru) - [1](https://telegra.ph/Otvety-na-voprosy-o-TON-DNS-kanalu-Investment-kingyru-CHast-1-08-05), [2](https://telegra.ph/Otvety-na-voprosy-o-TON-DNS-kanalu-Investment-kingyru-CHast-2-08-06), [3](https://telegra.ph/Otvety-na-voprosy-o-TON-DNS-kanalu-Investment-kingyru-CHast-3-08-09) # Specification @@ -143,10 +143,7 @@ proto_list_next$1 head:Protocol tail:ProtoList = ProtoList; -cap_method_seqno#5371 = SmcCapability; -cap_method_pubkey#71f4 = SmcCapability; cap_is_wallet#2177 = SmcCapability; -cap_name#ff name:Text = SmcCapability; cap_list_nil$0 = SmcCapList; cap_list_next$1 head:SmcCapability tail:SmcCapList = SmcCapList; @@ -193,3 +190,13 @@ None # Future possibilities 1. Implement private (encrypted) fields + +# Changelog + +* 20 Dec 2023 - deleted unused capabilities: + + ``` + cap_method_seqno#5371 = SmcCapability; + cap_method_pubkey#71f4 = SmcCapability; + cap_name#ff name:Text = SmcCapability; + ``` diff --git a/text/0085-sbt-standard.md b/text/0085-sbt-standard.md index 3808e7be..b93f3106 100644 --- a/text/0085-sbt-standard.md +++ b/text/0085-sbt-standard.md @@ -34,8 +34,10 @@ forward_payload:^Cell with_content:Bool = InternalMsgBody; `with_content` - if true, SBT's content cell will be included in message to contract. -**Should do:** +**Should be rejected if:** +* Sender address is not the owner's address. +**Otherwise should do:** Send message with TL-B schema to `dest` contract: ``` ownership_proof#0524c7ae query_id:uint64 item_id:uint256 owner:MsgAddress diff --git a/text/0000-ton-connect.md b/text/0115-ton-connect.md similarity index 98% rename from text/0000-ton-connect.md rename to text/0115-ton-connect.md index 635c44f1..74a0876c 100644 --- a/text/0000-ton-connect.md +++ b/text/0115-ton-connect.md @@ -1,4 +1,4 @@ -- **TEP**: [0](https://github.com/ton-blockchain/TEPs/pull/0) +- **TEP**: [115](https://github.com/ton-blockchain/TEPs/blob/master/text/0115-ton-connect.md) - **title**: TON Connect - **status**: Active - **type**: Core diff --git a/text/0160-dispatch-queue.md b/text/0160-dispatch-queue.md new file mode 100644 index 00000000..201cd32f --- /dev/null +++ b/text/0160-dispatch-queue.md @@ -0,0 +1,66 @@ +- **TEP**: [160](https://github.com/ton-blockchain/TEPs/pull/160) +- **title**: Dispatch Queue +- **status**: Implemented +- **type**: Core +- **created**: 13.06.2024 +- **replaces**: - +- **replaced by**: - + +# Summary +From user perspective TON functions as a multithreaded distributed operating system for decentralized applications (dApps). As any operation system TON implements scheduling mechanism for balancing resource consumption across multiple dApps. Previously this balancing was primarly based on sharding, that is moving resource-intensive processes to separate shard, however now we propose to add on top of sharding level balancing, additional introshard balancing, that will prevent a resource monopolization by single dApp that could lead to performance issues for other dApps on the same shard. In particular we propose to add additional intermediate queue between smart-contract and OutMsgQueue - the Dispatch Queue. This intermediate Queue will allow to schedule messages for processing in more distributed manner. + +# Motivation + +For now the only mechanism of load distribution is sharding: if some shard has too much load it may be divided to two sub-shards. While this indeed helps, there are limitations that sometimes make this mechanims not ideal on practice: finite (and relatively large) time of split/merge of shards, edgecases when load is unevenly distributed inside shard, split limit in network configuration (to make some other node mechanisms predictable) etc. This may affext user experience, in particular predictability and smoothness, since time of chain of transactions execution is dependent on other protocols simultaneously running in the network. The goal of this proposal to better distribute the load and prevent resource monopolization by single, instead providing more predictable execution time for all users and protocols. + +# Guide + +## Dispatch Queue +To balance load, we introduce an additional mechanism called the _Dispatch Queue_. When contract sends a message, it may either enter the Dispatch Queue (before the Collator moves some messages from the Dispatch Queue to the OutMsgQueue later on block collation) or directly enter OutMsgQueue. This intermediate step allows for a more even distribution of load among all dApps running in parallel. + +The Dispatch Queue is organized as a set of outgoing message queues for each account. When the collator forwards messages to the OutMsgQueue, it maintains lt-order: a message from Account A with `lt1` will move to the OutMsgQueue before a message from Account A with `lt2` if `lt1 < lt2`. However, this order is not maintained for messages from different accounts. For example, a message from Account A with `lt1 > lt2` may be processed before a message from Account B with lt2 if there is a significant backlog of messages from Account B. + +This logic is not new to TON; it previously operated at the inter-shard level: if Shard1 had a large number of incoming messages, it could fall behind in `lt` compared to Shard2, which would process all its messages without waiting for lt-parity with Shard1. + +With the Dispatch Queue, we extend this behavior to the (virtual) AccountChain level, effectively unlocking fully parallel running of individual AccountChains inside ShardChains! + +Another crucial rule is that the first message from a transaction (given there is no dispatching queue for the sending address) goes directly to the OutMsgQueue. This means contracts implementing a 1-message-in-1-message-out transaction logic avoid message dispatching. + + + +# Specification + +## TLB scheme changes: +Added +- `msg_envelope_v2` constructor for `MsgEnvelope` with `metadata` and `deferred_lt` +- `msg_metadata#0 depth:uint32 initiator_addr:MsgAddressInt initiator_lt:uint64 = MsgMetadata;` +- new `InMsg` and `OutMsg` constructors for messages that came in and out from DispatchQueue +- `dispatch_queue` field to `OutMsgQueueInfo` that effectively contains `mapping{Account->mapping{lt->Message}}` with augmentation that allows effecient message lt-ordering. + +## Guarantees and Protocol Development Impact +If your protocol processes incoming messages without extensive transaction-graph branching, you will generally remain unaffected. However, if your protocol includes significant branching, some branches may be distributed over time to avoid interfering with other dApps operating within the same shard. + +For example, in scenarios like `A-(m1)->B | A-(m2)->C | C-(m3)->B`, under low sharding, the process remains unchanged: `m1` will reach B earlier than `m3`. This holds because messages from A will always reach the OutMsgQueue of A's shard in lt order: first `m1`, then `m2`. And if shards A', B', and C' are neighbors, C's shard cannot process `m3` with lt strictly higher than `m1` first. + +Currently, the TON network is configured so that all shards are neighbors. However, given the rapid user base growth, we must consider dapp protocol changes for a future with more than 16 shards, where a message from A to B may pass through an intermediate hop (see hypercube routing). + +In such cases, each side of the triangle `A-(m1)->B | A-(m2)->C | C-(m3)->B` may include more edges: `A-(m1)->B` could become `A-(m1)->[Intermediate hop]-(m1)->B`, transforming the triangle into a polygon with less predictable order. If your protocol requires strict ordering, it can be achieved through an additional "synchronization" account S, as messages from S to B will be processed in the order they were sent from account S. + +## Additional Features +With introduction of dispatch queue we additionally extend message envelopes (structures that wrap messages during routing in TON) to contain metadata such as the original transaction ID (in the form of `initiator_addr:MsgAddressInt initiator_lt:uint64`) and depth in the graph. This helps indexers manage very large transaction chains (sometimes called "traces"). + +# Drawbacks + +1. This is significant and deep change of how node process messages that adds additional complexity. +2. This introduce some (but limited, and it may be limited further) way for collators to reorder and prioritize some messages, that open possibilities of MEV, which may be considered controversial. + + +# Rationale and alternatives + +Despite being quite significant, Dispatch Queue actually doesn't affect behavior of all other parts of the system, because validators continue to import messages from OutMsgQueue the same way, sharding works the same way etc. + +Among alternatives we considered message postponement inside OutMsgQueue which, howver, requres more significant changes on sharding/collation levels and also has less flexibility. + +# Future possibilities + +Dispatching rules, the rules of in which order messages from Dispatch QUeue goes to OutMsgQueue, maybe developed further to better suit practcal needs. This changes won't require consensus. Some additional fields in the metadata were added to give collator more context during dispatching (it probably won't be used in the first implementation). Besides it is possible that in the future som of metadata, in particular `initiator_addr` may be done accessible to TVM runtime.