diff --git a/content/foundations/network/adnl-udp.mdx b/content/foundations/network/adnl-udp.mdx index cd26e627e..79cf3494c 100644 --- a/content/foundations/network/adnl-udp.mdx +++ b/content/foundations/network/adnl-udp.mdx @@ -3,7 +3,7 @@ title: "ADNL over UDP: internode communication" sidebarTitle: "ADNL UDP" --- -ADNL over UDP is the protocol used by TON nodes to communicate with each other. It serves as the foundation for higher-level protocols such as the [distributed hash table (DHT)](https://github.com/ton-blockchain/ton/tree/v2026.06/dht) and [Reliable Large Datagram Protocol (RLDP)](https://github.com/ton-blockchain/ton/tree/v2026.06/rldp2). +ADNL over UDP is the protocol used by TON nodes to communicate with each other. It serves as the foundation for higher-level protocols such as the [distributed hash table (DHT)](/foundations/network/dht) and [Reliable Large Datagram Protocol (RLDP)](/foundations/network/rldp). Unlike [ADNL over TCP](/foundations/network/adnl-tcp), the UDP implementation uses channels for ongoing communication and establishes the connection when the first data exchange occurs. Initial packets use public-key encryption and identity signatures, while established channels use directional symmetric keys. diff --git a/content/foundations/network/adnl.mdx b/content/foundations/network/adnl.mdx index d30f8f45e..d8ffc7144 100644 --- a/content/foundations/network/adnl.mdx +++ b/content/foundations/network/adnl.mdx @@ -1,11 +1,11 @@ --- -title: "Abstract Datagram Network Layer" +title: "Abstract Datagram Network Layer (ADNL) overview" sidebarTitle: "ADNL" --- The Abstract Datagram Network Layer (ADNL) is the core networking protocol of the TON network. It is a peer-to-peer, unreliable datagram protocol that operates over both [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol) and [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol). -Higher-level protocols such as [Reliable Large Datagram Protocol (RLDP)](https://github.com/ton-blockchain/ton/tree/v2026.06/rldp2) and the [distributed hash table (DHT)](https://github.com/ton-blockchain/ton/tree/v2026.06/dht) are built on top of ADNL. +Higher-level protocols such as [Reliable Large Datagram Protocol (RLDP)](/foundations/network/rldp) and the [distributed hash table (DHT)](/foundations/network/dht) are built on top of ADNL. ## ADNL address @@ -17,7 +17,7 @@ An ADNL address is derived as: address = SHA-256(type_id || public_key) ``` -The hash input is the complete boxed TL serialization of the public key, and the `type_id` is a `uint32` constructor ID serialized in little-endian order. For example, the Ed25519 public-key constructor has numeric ID `0x4813b4c6`, so its wire bytes are `c6 b4 13 48` followed by the 32-byte public key. The corresponding private key must be known to receive and decrypt messages sent to a given address. +The hash input is the complete boxed [TL](https://core.telegram.org/mtproto/TL) serialization of the public key, and the `type_id` is a `uint32` constructor ID serialized in little-endian order. For example, the Ed25519 public-key constructor has numeric ID `0x4813b4c6`, so its wire bytes are `c6 b4 13 48` followed by the 32-byte public key. The corresponding private key must be known to receive and decrypt messages sent to a given address. current UNIX time - 600`. + +### Value use + +Once verification succeeds and the `ttl` has not expired, the client extracts `value:bytes`. The `ttl` is a UNIX timestamp, with values more than 3,660 seconds into the future rejected. For ADNL address lookups, `value` contains an `adnl.addressList` with IP addresses and ports. + +The client uses the `id:PublicKey` from the key description as the server key when connecting. + +## Blockchain node discovery + +The DHT is also used to discover nodes storing blockchain data for specific workchains and shards. + +### Overlay key construction + +1. The client fills in the TL structure: + + ```tl + tonNode.shardPublicOverlayId workchain:int shard:long zero_state_file_hash:int256 = tonNode.ShardPublicOverlayId; + ``` + + For the masterchain: `workchain = -1`, `shard = -9223372036854775808` (`0x8000000000000000`). The `zero_state_file_hash` comes from the `validator > zero_state` section of the global config. + +1. The client serializes and hashes the structure to get the overlay ID. + +1. The client wraps the overlay ID in `pub.overlay name:bytes = PublicKey`, serializes it, and hashes it to get the overlay public-key hash. + +1. The client constructs `dht.key` with the overlay public-key hash as `id`, `"nodes"` as `name`, and `0` as `idx`. It hashes this structure to obtain the key ID for `dht.findValue`. + +The result uses `dht.updateRule.overlayNodes`. After validation, the returned public keys identify nodes with blockchain data. The client hashes these keys to get ADNL addresses, then looks up each address in the DHT to obtain connection details. + +To discover additional nodes in the same shard, the client sends [`overlay.getRandomPeers`](https://github.com/ton-blockchain/ton/blob/v2026.06/tl/generate/scheme/ton_api.tl#L257). + +## See also + +- [ADNL overview](/foundations/network/adnl) +- [ADNL over UDP](/foundations/network/adnl-udp) +- [DHT implementation in the TON monorepo](https://github.com/ton-blockchain/ton/tree/v2026.06/dht) +- [DHT server implementation in the TON monorepo](https://github.com/ton-blockchain/ton/tree/v2026.06/dht-server) +- [DHT in The Open Network whitepaper](/foundations/whitepapers/ton/#3-2-ton-dht%3A-kademlia-like-distributed-hash-table) diff --git a/content/foundations/network/meta.json b/content/foundations/network/meta.json index 2057155fc..6e61d86dd 100644 --- a/content/foundations/network/meta.json +++ b/content/foundations/network/meta.json @@ -2,6 +2,8 @@ "$schema": "../../../meta-schema.json", "title": "Network protocols", "pages": [ + "rldp", + "dht", "adnl", "adnl-tcp", "adnl-udp" diff --git a/content/foundations/network/rldp.mdx b/content/foundations/network/rldp.mdx new file mode 100644 index 000000000..2a5e93b1e --- /dev/null +++ b/content/foundations/network/rldp.mdx @@ -0,0 +1,185 @@ +--- +title: "Reliable Large Datagram Protocol (RLDP)" +sidebarTitle: "RLDP" +--- + + + With the introduction of the [sub-second upgrade](/ecosystem/subsecond), blockchain nodes now use [QUIC](https://en.wikipedia.org/wiki/QUIC) instead of RLDP for internal node communication. + + +The Reliable Large Datagram Protocol (RLDP) runs on top of [ADNL UDP](/foundations/network/adnl-udp) and transfers data that does not fit in one ADNL datagram. It uses [Forward Error Correction (FEC)](https://en.wikipedia.org/wiki/Error_correction_code) to recover from packet loss. Its newer version, RLDP2, also uses acknowledgment packets, loss detection, pacing, and congestion control. + +RLDP has been used throughout TON infrastructure for downloading blocks from other nodes, transferring data, and accessing [TON Sites](/foundations/web3/ton-sites) and [TON Storage](/foundations/web3/ton-storage). + + + The [`rldp-http-proxy` in the TON monorepo](https://github.com/ton-blockchain/ton/tree/v2026.06/rldp-http-proxy) uses RLDP2 for accessing TON Sites. + + +## Protocol + +The [TL](https://core.telegram.org/mtproto/TL) schema retains structures for RLDP and RLDP2: + +```tl +fec.raptorQ data_size:int symbol_size:int symbols_count:int = fec.Type; +fec.roundRobin data_size:int symbol_size:int symbols_count:int = fec.Type; +fec.online data_size:int symbol_size:int symbols_count:int = fec.Type; + +rldp2.messagePart transfer_id:int256 fec_type:fec.Type part:int total_size:long seqno:int data:bytes = rldp2.MessagePart; +rldp2.confirm transfer_id:int256 part:int max_seqno:int received_mask:int received_count:int = rldp2.MessagePart; +rldp2.complete transfer_id:int256 part:int = rldp2.MessagePart; + +rldp.messagePart transfer_id:int256 fec_type:fec.Type part:int total_size:long seqno:int data:bytes = rldp.MessagePart; +rldp.confirm transfer_id:int256 part:int seqno:int = rldp.MessagePart; +rldp.complete transfer_id:int256 part:int = rldp.MessagePart; + +rldp.message id:int256 data:bytes = rldp.Message; +rldp.query query_id:int256 max_answer_size:long timeout:int data:bytes = rldp.Message; +rldp.answer query_id:int256 data:bytes = rldp.Message; +``` + +The message-part, confirmation, and completion structures are serialized as custom ADNL messages and transmitted over [ADNL UDP](/foundations/network/adnl-udp). RLDP2 reuses `rldp.message`, `rldp.query`, and `rldp.answer` for the decoded payload. + +- `rldp.message` carries a one-way application payload. +- `rldp.query` carries a request, a `query_id`, a maximum answer size, and a UNIX timeout. +- `rldp.answer` carries the application response and the request's `query_id`. The querying endpoint rejects response data larger than `max_answer_size`. + +The RLDP2 connection defaults to a 7,680-byte inbound limit. The `send_query_ex` registers `max_answer_size` as the limit for the answer transfer. + +## Transfer mechanism + +1. The sender generates a random `transfer_id`. +1. The sender splits the payload into parts and creates a [RaptorQ](https://en.wikipedia.org/wiki/Raptor_code#RaptorQ_code) encoder for each part. The reference RLDP2 implementation uses parts of up to 2,000,000 bytes and 768-byte symbols. +1. The sender transmits encoded symbols in `rldp2.messagePart`. +1. The receiver reports the greatest received sequence number, a receive mask, and a total receive count in `rldp2.confirm`. +1. The sender uses this feedback to estimate round-trip time, bandwidth, and loss. It paces symbols and adjusts its congestion window with a [BBR](https://en.wikipedia.org/wiki/TCP_congestion_control#TCP_BBR)-style controller. +1. The sender stops transmitting a part after `rldp2.complete` arrives or the transfer times out. + +The receiver decodes each part after collecting enough independent symbols, concatenates the parts in order, and deserializes the result as `rldp.message`, `rldp.query`, or `rldp.answer`. An answer uses the request's `transfer_id` with every bit inverted. + +## Forward Error Correction + +The TL schema defines RoundRobin, Online, and RaptorQ FEC types. The reference RLDP2 implementation accepts only RaptorQ — its FEC parser rejects the other constructors. + +### RaptorQ + +RaptorQ divides data into fixed-size source symbols. An encoder can derive additional repair symbols from the same source data. + +After receiving enough independent source and repair symbols, the decoder reconstructs the original part without requesting specific lost symbols. + +RLDP2 sends an initial set of source and repair symbols, then uses acknowledgments and loss estimates to decide how many additional symbols to send. The receiver sends `rldp2.complete` after decoding a part. + + + [RaptorQ encoder setup in the reference RLDP2 implementation](https://github.com/ton-blockchain/ton/blob/v2026.06/rldp2/OutboundTransfer.cpp#L27-L40). + + +## RLDP-HTTP + +[TON Sites](/foundations/web3/ton-sites) use HTTP over RLDP. The host runs a standard HTTP web server with `rldp-http-proxy` alongside it. Incoming requests from the TON network arrive through RLDP2, and the proxy forwards them to the local HTTP server. On the client side, a local proxy, such as [Tonutils Proxy](https://github.com/xssnick/Tonutils-Proxy), converts outgoing HTTP requests into RLDP. + +HTTP over RLDP uses these TL structures: + +```tl +http.header name:string value:string = http.Header; +http.payloadPart data:bytes trailer:(vector http.header) last:Bool = http.PayloadPart; +http.response http_version:string status_code:int reason:string headers:(vector http.header) no_payload:Bool = http.Response; +http.proxy.capabilities capabilities:long = http.proxy.Capabilities; + +http.request id:int256 method:string url:string http_version:string headers:(vector http.header) = http.Response; +http.getNextPayloadPart id:int256 seqno:int max_chunk_size:int = http.PayloadPart; +http.proxy.getCapabilities capabilities:long = http.proxy.Capabilities; +``` + +The request-response flow: + +1. The client sends `http.request` via `rldp.query`. +1. If the request has a payload, the server sends `http.getNextPayloadPart` queries to the client. + - The client responds with `http.payloadPart` chunks and increments `seqno` until `last` is true. +1. The server sends `http.response`. +1. If `no_payload` is false, the client sends `http.getNextPayloadPart` queries to the server using the same chunked mechanism. + +The proxy uses bit 0 (value 1) in the `http.proxy.getCapabilities` and `http.proxy.capabilities` exchange to advertise RLDP2 support. It requests payload chunks of up to 2,095,104 bytes and caps larger `max_chunk_size` values at that size. + +## TON Site request example + +This example demonstrates requesting `foundation.ton`, assuming the ADNL address has been resolved via DNS and a connection has been established over [ADNL UDP](/foundations/network/adnl-udp). The proxy requires the peer to advertise RLDP2 support. + +### GET request + +The client fills the following structure: + +```tl +http.request id:int256 method:string url:string http_version:string headers:(vector http.header) = http.Response; +``` + +The client serializes `http.request`: + +```text +e191b161 -- TL ID http.request +116505dac8a9a3cdb464f9b5dd9af78594f23f1c295099a9b50c8245de471194 -- id (random) +03 474554 -- method = "GET" +16 687474703a2f2f666f756e646174696f6e2e746f6e2f 00 -- url = "http://foundation.ton/" +08 485454502f312e31 000000 -- http_version = "HTTP/1.1" +01000000 -- headers (1 entry) + 04 486f7374 000000 -- name = "Host" + 0e 666f756e646174696f6e2e746f6e 00 -- value = "foundation.ton" +``` + +The client then wraps the serialized `http.request` in `rldp.query` and serializes it. The following partial snippet shows the field layout. The placeholders represent values that the client supplies before serialization: + +```text +694d798a -- TL ID rldp.query + -- 32 random bytes +0040000000000000 -- max_answer_size = 16 KiB (16,384 bytes) + -- future UNIX timestamp encoded as a TL int + -- TL bytes value +``` + +### RaptorQ encoding + +1. The sender uses the 768-byte symbol size used by the reference RLDP2 implementation. +1. For this one-part request, the sender sets `data_size` and `total_size` to the serialized `rldp.query` length. The RaptorQ encoder handles the final short symbol. +1. The sender creates a [RaptorQ encoder](https://github.com/ton-blockchain/ton/blob/v2026.06/rldp2/OutboundTransfer.cpp#L27-L40). + +### Packet transmission + +The sender transmits encoded symbols in `rldp2.messagePart`: + +```tl +rldp2.messagePart transfer_id:int256 fec_type:fec.Type part:int total_size:long seqno:int data:bytes = rldp2.MessagePart; +``` + +- `transfer_id` – random `int256`, same for all parts of this transfer. +- `fec_type` – `fec.raptorQ` with the part's byte length, `symbol_size = 768`, and the encoder's source-symbol count. +- `part` – zero-based part index. Start with 0. +- `total_size` – complete serialized `rldp.query` size across all parts. +- `seqno` – starts at 0, incremented for each packet. +- `data` – encoded symbol (768 bytes). + +The sender wraps each structure in `adnl.message.custom` and transmits it over ADNL UDP. It processes `rldp2.confirm` feedback and continues according to its loss-recovery and pacing logic until `rldp2.complete` arrives. + +### Response processing + +The response arrives as `rldp2.messagePart` messages inside `adnl.message.custom`. Its `transfer_id` is the request transfer ID with all 256 bits inverted. + +1. The receiver extracts FEC parameters (`data_size`, `symbol_size`, `symbols_count`) from the first received message. +1. The receiver initializes a RaptorQ decoder. +1. The receiver feeds each received symbol and its `seqno` into the decoder. +1. The receiver sends `rldp2.confirm` as symbols arrive. +1. The receiver attempts decoding when the decoder reports that enough symbols are available. On success, it sends `rldp2.complete` for that part. + +At this point, the decoded `rldp.answer` contains an `http.response` with the status code and headers, but not necessarily the body. + +- If `no_payload` is `true`, the response has no body and the request is complete. +- If `no_payload` is `false`, the client fetches the body separately: + + 1. The client sends an `http.getNextPayloadPart` request with incrementing `seqno`. The proxy requests at most 2,095,104 bytes per chunk. + 1. The client wraps each request in a new `rldp.query` transfer. + 1. The client repeats the request until the returned `http.payloadPart` has `last` set to `true`. + +## See also + +- [ADNL overview](/foundations/network/adnl) +- [TON Proxy](/foundations/web3/ton-proxy) +- [TON Sites](/foundations/web3/ton-sites) +- [RLDP implementation in the TON monorepo](https://github.com/ton-blockchain/ton/tree/v2026.06/rldp) +- [RLDP v2 implementation in the TON monorepo](https://github.com/ton-blockchain/ton/tree/v2026.06/rldp2) diff --git a/content/foundations/whitepapers/ton.mdx b/content/foundations/whitepapers/ton.mdx index 996913383..5cf517922 100644 --- a/content/foundations/whitepapers/ton.mdx +++ b/content/foundations/whitepapers/ton.mdx @@ -1467,7 +1467,7 @@ The ADNL, being an unreliable (small-size) datagram protocol based on 256-bit ab A reliable arbitrary-size datagram protocol built upon the ADNL, called RLDP, is used instead of a TCP-like protocol. This reliable datagram protocol can be employed, for instance, to send RPC queries to remote hosts and receive answers from them (cf. [4.1.5](#4-1-5-pure-network-services-ton-sites-and-ton-services)). -### 3.2 TON DHT: Kademlia-like Distributed Hash Table +### 3.2 TON DHT: Kademlia-like Distributed Hash Table The *TON Distributed Hash Table (DHT)* plays a crucial role in the networking part of the TON Project, being used to locate other nodes in the network. For example, a client wanting to commit a transaction into a shardchain might want to find a validator or a collator of that shardchain, or at least some node that might relay the client's transaction to a collator. This can be done by looking up a special key in the TON DHT. Another important application of the TON DHT is that it can be used to quickly populate a new node's neighbor table (cf. [3.1.7](#3-1-7-zero-channel-and-the-bootstrap-problem)), simply by looking up a random key, or the new node's address. If a node uses proxying and tunneling for its inbound datagrams, it publishes the tunnel identifier and its entry point (e.g., IP address and UDP port) in the TON DHT; then all nodes wishing to send datagrams to that node will obtain this contact information from the DHT first. diff --git a/content/subsecond.mdx b/content/subsecond.mdx index 02b136c35..16f18c5a8 100644 --- a/content/subsecond.mdx +++ b/content/subsecond.mdx @@ -1,7 +1,6 @@ --- title: "How to adopt sub-second finality" sidebarTitle: "Sub-second finality" -tag: "take action" --- The TON Core team has [released Catchain 2.0](https://t.me/toncore/104) on mainnet. This consensus upgrade enables sub-second block finality, reducing the block interval from about 2.5s to about 400ms. diff --git a/docs.json b/docs.json index 5079b8a27..257fc1d1f 100644 --- a/docs.json +++ b/docs.json @@ -95,7 +95,7 @@ }, { "source": "/v3/concepts/dive-into-ton/ton-ecosystem/wallet-apps", - "destination": "https://old-docs.ton.org/v3/concepts/dive-into-ton/ton-ecosystem/wallet-apps", + "destination": "/onboarding/wallet-apps/web", "permanent": true }, { @@ -260,7 +260,7 @@ }, { "source": "/v3/documentation/smart-contracts/getting-started/testnet", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/getting-started/testnet", + "destination": "/foundations/glossary#testnet", "permanent": true }, { @@ -285,7 +285,7 @@ }, { "source": "/v3/documentation/smart-contracts/message-management/sending-messages", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/sending-messages", + "destination": "/languages/func/cookbook#messages", "permanent": true }, { @@ -295,22 +295,22 @@ }, { "source": "/v3/documentation/smart-contracts/message-management/external-messages", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/external-messages", + "destination": "/foundations/messages/external-in", "permanent": true }, { "source": "/v3/documentation/smart-contracts/message-management/non-bounceable-messages", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/non-bounceable-messages", + "destination": "/foundations/messages/modes", "permanent": true }, { "source": "/v3/documentation/smart-contracts/message-management/message-modes-cookbook", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/message-modes-cookbook", + "destination": "/foundations/messages/modes", "permanent": true }, { "source": "/v3/documentation/smart-contracts/message-management/ecosystem-messages-layout", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/ecosystem-messages-layout", + "destination": "/contracts/standard/overview", "permanent": true }, { @@ -370,12 +370,12 @@ }, { "source": "/v3/documentation/smart-contracts/contracts-specs/nominator-pool", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/contracts-specs/nominator-pool", + "destination": "/nodes/staking/nominator-pools", "permanent": true }, { "source": "/v3/documentation/smart-contracts/contracts-specs/single-nominator-pool", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/contracts-specs/single-nominator-pool", + "destination": "/nodes/staking/single-nominator", "permanent": true }, { @@ -740,17 +740,17 @@ }, { "source": "/v3/documentation/network/protocols/dht/overview", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/dht/overview", + "destination": "/foundations/network/dht", "permanent": true }, { "source": "/v3/documentation/network/protocols/dht/deep-dive", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/dht/deep-dive", + "destination": "/foundations/network/dht", "permanent": true }, { "source": "/v3/documentation/network/protocols/rldp", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/rldp", + "destination": "/foundations/network/rldp", "permanent": true }, { @@ -795,7 +795,7 @@ }, { "source": "/v3/documentation/data-formats/layout/blocks", - "destination": "https://old-docs.ton.org/v3/documentation/data-formats/layout/blocks", + "destination": "https://github.com/ton-blockchain/ton/blob/bbc3bc6d52abbe3a7f852b22050708166fdaafbc/crypto/block/block.tlb#L450-L469", "permanent": true }, { @@ -855,27 +855,27 @@ }, { "source": "/v3/documentation/tvm/specification/runvm", - "destination": "https://old-docs.ton.org/v3/documentation/tvm/specification/runvm", + "destination": "/tvm/instructions", "permanent": true }, { "source": "/v3/documentation/tvm/changelog/tvm-upgrade-2025-02", - "destination": "https://old-docs.ton.org/v3/documentation/tvm/changelog/tvm-upgrade-2025-02", + "destination": "/tvm/overview", "permanent": true }, { "source": "/v3/documentation/tvm/changelog/tvm-upgrade-2024-04", - "destination": "https://old-docs.ton.org/v3/documentation/tvm/changelog/tvm-upgrade-2024-04", + "destination": "/tvm/overview", "permanent": true }, { "source": "/v3/documentation/tvm/changelog/tvm-upgrade-2023-07", - "destination": "https://old-docs.ton.org/v3/documentation/tvm/changelog/tvm-upgrade-2023-07", + "destination": "/tvm/overview", "permanent": true }, { "source": "/learn/tvm-instructions/tvm-upgrade", - "destination": "https://old-docs.ton.org/learn/tvm-instructions/tvm-upgrade", + "destination": "/tvm/overview", "permanent": true }, { @@ -1100,12 +1100,12 @@ }, { "source": "/v3/guidelines/smart-contracts/howto/multisig", - "destination": "https://old-docs.ton.org/v3/guidelines/smart-contracts/howto/multisig", + "destination": "/languages/fift/multisig", "permanent": true }, { "source": "/v3/guidelines/smart-contracts/howto/multisig-js", - "destination": "https://old-docs.ton.org/v3/guidelines/smart-contracts/howto/multisig-js", + "destination": "/languages/fift/multisig", "permanent": true }, { @@ -1150,32 +1150,32 @@ }, { "source": "/v3/guidelines/dapps/transactions/overview", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/transactions/overview", + "destination": "/foundations/messages/overview", "permanent": true }, { "source": "/v3/guidelines/dapps/transactions/foundations-of-blockchain", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/transactions/foundations-of-blockchain", + "destination": "/start-here", "permanent": true }, { "source": "/v3/guidelines/dapps/transactions/message-driven-execution", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/transactions/message-driven-execution", + "destination": "/foundations/messages/overview", "permanent": true }, { "source": "/v3/guidelines/dapps/transactions/hash-based-tracking", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/transactions/hash-based-tracking", + "destination": "/applications/ton-connect/how-to/message-lookup", "permanent": true }, { "source": "/v3/guidelines/dapps/transactions/api-based-retrieval", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/transactions/api-based-retrieval", + "destination": "/api/overview", "permanent": true }, { "source": "/v3/guidelines/dapps/transactions/explore-transactions", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/transactions/explore-transactions", + "destination": "/onboarding/explorers", "permanent": true }, { @@ -1235,7 +1235,7 @@ }, { "source": "/v3/guidelines/dapps/tutorials/nft-minting-guide", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/tutorials/nft-minting-guide", + "destination": "/contracts/standard/tokens/nft/overview", "permanent": true }, { @@ -1245,7 +1245,7 @@ }, { "source": "/v3/guidelines/dapps/tutorials/zero-knowledge-proofs", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/tutorials/zero-knowledge-proofs", + "destination": "/contracts/techniques/zero-knowledge", "permanent": true }, { @@ -1475,7 +1475,7 @@ }, { "source": "/v3/guidelines/nodes/maintenance-guidelines/mytonctrl-remote-controller", - "destination": "https://old-docs.ton.org/v3/guidelines/nodes/maintenance-guidelines/mytonctrl-remote-controller", + "destination": "/nodes/cpp/mytonctrl/overview", "permanent": true }, { @@ -1655,17 +1655,17 @@ }, { "source": "/v3/guidelines/web3/ton-proxy-sites/connect-with-ton-proxy", - "destination": "https://old-docs.ton.org/v3/guidelines/web3/ton-proxy-sites/connect-with-ton-proxy", + "destination": "/foundations/web3/ton-proxy", "permanent": true }, { "source": "/v3/guidelines/web3/ton-proxy-sites/how-to-open-any-ton-site", - "destination": "https://old-docs.ton.org/v3/guidelines/web3/ton-proxy-sites/how-to-open-any-ton-site", + "destination": "/foundations/web3/ton-proxy", "permanent": true }, { "source": "/v3/guidelines/web3/ton-proxy-sites/site-and-domain-management", - "destination": "https://old-docs.ton.org/v3/guidelines/web3/ton-proxy-sites/site-and-domain-management", + "destination": "/foundations/web3/ton-proxy", "permanent": true }, { @@ -1690,7 +1690,7 @@ }, { "source": "/v3/guidelines/web3/ton-storage/storage-faq", - "destination": "https://old-docs.ton.org/v3/guidelines/web3/ton-storage/storage-faq", + "destination": "/foundations/web3/ton-storage", "permanent": true }, { @@ -1740,7 +1740,7 @@ }, { "source": "/participate/web3/site-management", - "destination": "https://old-docs.ton.org/v3/guidelines/web3/ton-proxy-sites/site-and-domain-management", + "destination": "/foundations/web3/ton-proxy", "permanent": true }, { @@ -1835,7 +1835,7 @@ }, { "source": "/develop/dapps/tutorials/collection-minting", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/tutorials/nft-minting-guide", + "destination": "/contracts/standard/tokens/nft/overview", "permanent": true }, { @@ -1845,7 +1845,7 @@ }, { "source": "/develop/dapps/tutorials/simple-zk-on-ton", - "destination": "https://old-docs.ton.org/v3/guidelines/dapps/tutorials/zero-knowledge-proofs", + "destination": "/contracts/techniques/zero-knowledge", "permanent": true }, { @@ -1955,12 +1955,12 @@ }, { "source": "/develop/smart-contracts/tutorials/multisig", - "destination": "https://old-docs.ton.org/v3/guidelines/smart-contracts/howto/multisig", + "destination": "/languages/fift/multisig", "permanent": true }, { "source": "/develop/smart-contracts/tutorials/multisig-js", - "destination": "https://old-docs.ton.org/v3/guidelines/smart-contracts/howto/multisig-js", + "destination": "/languages/fift/multisig", "permanent": true }, { @@ -1995,7 +1995,7 @@ }, { "source": "/develop/smart-contracts/environment/testnet", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/getting-started/testnet", + "destination": "/foundations/glossary#testnet", "permanent": true }, { @@ -2015,22 +2015,22 @@ }, { "source": "/develop/smart-contracts/guidelines/ecosystem-messages-layout", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/ecosystem-messages-layout", + "destination": "/contracts/standard/overview", "permanent": true }, { "source": "/develop/smart-contracts/messages", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/sending-messages", + "destination": "/languages/func/cookbook#messages", "permanent": true }, { "source": "/develop/smart-contracts/guidelines/message-modes-cookbook", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/message-modes-cookbook", + "destination": "/foundations/messages/modes", "permanent": true }, { "source": "/develop/smart-contracts/guidelines/external-messages", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/external-messages", + "destination": "/foundations/messages/external-in", "permanent": true }, { @@ -2040,7 +2040,7 @@ }, { "source": "/develop/smart-contracts/guidelines/non-bounceable-messages", - "destination": "https://old-docs.ton.org/v3/documentation/smart-contracts/message-management/non-bounceable-messages", + "destination": "/foundations/messages/modes", "permanent": true }, { @@ -2235,12 +2235,12 @@ }, { "source": "/learn/networking/ton-dht", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/dht/overview", + "destination": "/foundations/network/dht", "permanent": true }, { "source": "/develop/network/dht", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/dht/deep-dive", + "destination": "/foundations/network/dht", "permanent": true }, { @@ -2250,7 +2250,7 @@ }, { "source": "/develop/network/rldp", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/rldp", + "destination": "/foundations/network/rldp", "permanent": true }, { @@ -2280,7 +2280,7 @@ }, { "source": "/develop/data-formats/block-layout", - "destination": "https://old-docs.ton.org/v3/documentation/data-formats/layout/blocks", + "destination": "https://github.com/ton-blockchain/ton/blob/bbc3bc6d52abbe3a7f852b22050708166fdaafbc/crypto/block/block.tlb#L450-L469", "permanent": true }, { @@ -2345,12 +2345,12 @@ }, { "source": "/learn/tvm-instructions/tvm-upgrade-2023-07", - "destination": "https://old-docs.ton.org/v3/documentation/tvm/changelog/tvm-upgrade-2023-07", + "destination": "/tvm/overview", "permanent": true }, { "source": "/learn/tvm-instructions/fee-calculation-instructions", - "destination": "https://old-docs.ton.org/v3/documentation/tvm/changelog/tvm-upgrade-2024-04", + "destination": "/tvm/instructions", "permanent": true }, { @@ -2590,7 +2590,7 @@ }, { "source": "/v3/documentation/data-formats/tlb/block-layout", - "destination": "https://old-docs.ton.org/v3/documentation/data-formats/layout/blocks", + "destination": "https://github.com/ton-blockchain/ton/blob/bbc3bc6d52abbe3a7f852b22050708166fdaafbc/crypto/block/block.tlb#L450-L469", "permanent": true }, { @@ -2610,12 +2610,12 @@ }, { "source": "/v3/documentation/network/protocols/dht/ton-dht", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/dht/overview", + "destination": "/foundations/network/dht", "permanent": true }, { "source": "/v3/documentation/network/protocols/dht/dht-deep-dive", - "destination": "https://old-docs.ton.org/v3/documentation/network/protocols/dht/deep-dive", + "destination": "/foundations/network/dht", "permanent": true }, { diff --git a/src/dictionaries/custom.txt b/src/dictionaries/custom.txt index 1ed02f725..011568298 100644 --- a/src/dictionaries/custom.txt +++ b/src/dictionaries/custom.txt @@ -68,6 +68,7 @@ Bahdanau Baranov basechain Basechain +BBR BCM BCP bene