feat(sharding): put in agreement with styleguide and port code samples to Tolk#2131
feat(sharding): put in agreement with styleguide and port code samples to Tolk#2131
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This comment has been minimized.
This comment has been minimized.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| ## NFT and jetton examples | ||
|
|
||
| Consider NFTs: the collection acts as the parent contract, and each NFT item is a child contract. The key in this case is the item index, and only the collection can set the initial owner. | ||
|
|
||
| For jettons, the parent contract is the minter, and the child contracts are user wallets. The key is the user's smart contract address, and the value is the user's token balance. | ||
|
|
||
| Both patterns follow the same principle: each key maps to a separate contract. In jetton protocols, there is a unique contract per user, while in NFT collections, there is one contract per item (by index) that is shared across all users. |
There was a problem hiding this comment.
[HIGH] Casing of “jetton” at sentence start
| ## NFT and jetton examples | |
| Consider NFTs: the collection acts as the parent contract, and each NFT item is a child contract. The key in this case is the item index, and only the collection can set the initial owner. | |
| For jettons, the parent contract is the minter, and the child contracts are user wallets. The key is the user's smart contract address, and the value is the user's token balance. | |
| Both patterns follow the same principle: each key maps to a separate contract. In jetton protocols, there is a unique contract per user, while in NFT collections, there is one contract per item (by index) that is shared across all users. |
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| ## Child contract address by key | ||
|
|
||
| The contract address depends on the initial data provided in [`StateInit`](/foundations/messages/deploy). To ensure that a child contract can be accessed using only the key, the initial data includes the key but does not include the associated value. As a result, the address of the child contract can be determined from the key alone. |
There was a problem hiding this comment.
[HIGH] Missing code font for StateInit
The identifier StateInit is referenced inside link text on this page without being consistently treated as a code-styled identifier across revisions. The style guide requires code identifiers to appear in code font with exact casing so they are visually distinct from surrounding prose and easy to scan. Using plain text for an identifier like StateInit reduces clarity, especially for readers skimming for specific technical terms. Keeping identifier formatting consistent across the docs also improves searchability and reduces the chance of misreading the term.
| ## Child contract address by key | |
| The contract address depends on the initial data provided in [`StateInit`](/foundations/messages/deploy). To ensure that a child contract can be accessed using only the key, the initial data includes the key but does not include the associated value. As a result, the address of the child contract can be determined from the key alone. | |
| ## Child contract address by key | |
| The contract address depends on the initial data provided in [`StateInit`](/foundations/messages/deploy). To ensure that a child contract can be accessed using only the key, the initial data includes the key but does not include the associated value. As a result, the address of the child contract can be determined from the key alone. |
Please leave a reaction 👍/👎 to this suggestion to improve future reviews for everyone!
| seqno: uint64, | ||
| todoChildCode: cell, | ||
| ): AutoDeployAddress { | ||
| val childStorage: TodoChildStorage = { |
There was a problem hiding this comment.
I guess the child StateInit only includes seqno, so two parents using the same child code and sequence number can derive the same child address. it also contradicts the caution above, because the child has no stored parent address to verify
to fix it is to include the parent address in the child's initial storage, pass it into address derivation, and verify it in the child handler
| val msg = lazy TodoParentMessage.fromSlice(in.body); | ||
|
|
||
| match (msg) { | ||
| DeployAnother => { |
There was a problem hiding this comment.
DeployAnother is accepted from any sender and spends ton("0.1") from the parent. If copied as-is, anyone can repeatedly trigger child deployments and drain the parent balance
either mark this handler as demo-only, or add authorization. For example:
struct TodoParentStorage {
+ // Initialize this field in the parent's StateInit during deployment.
+ adminAddress: address
numChildren: uint64 = 0
// Parent must know the child contract code to deploy new instances.
todoChildCode: cell
} DeployAnother => {
var storage = lazy TodoParentStorage.load();
+ assert (in.senderAddress == storage.adminAddress) throw 0xFFFF;
storage.numChildren += 1;|
|
||
| // Send a message to the auto-calculated address and attach | ||
| // the child code and initial data so the child is deployed. | ||
| val deployMsg = createMessage({ |
There was a problem hiding this comment.
the createMessage call omits explicit bounce behavior. The Tolk message docs say createMessage should specify bounce behavior, and the full examples in this repo do so
https://docs.ton.org/languages/tolk/features/message-handling#bouncemode-in-createmessage
I'd add an explicit mode, for example:
val deployMsg = createMessage({
+ bounce: BounceMode.Only256BitsOfBody,
dest: calcDeployedTodoChild(
storage.numChildren,
storage.todoChildCode,
),| Some protocols need to store a lot of information in contracts, for example, token contracts with many users. In TON, there is a limit on how much can be stored in a single contract. The solution is to split the data across multiple contracts. | ||
|
|
||
| In such protocols, there is a child contract that initially contains the information identified by a key. In some protocols, it is important to know the Parent contract, which acts as the information manager. | ||
| Each such contract, referred to as a child contract, is associated with a key that allows direct access to the required contract and its data. Some protocols also introduce a _parent_ contract that coordinates child contracts. |
There was a problem hiding this comment.
"a key that allows direct access to the required contract and its data" repeats "contract" a bit awkwardly. it makes sense to read cleaner as something like: a key that uniquely determines its address
| self.numChildren = 0; | ||
| } | ||
| fun onInternalMessage(in: InMessage) { | ||
| val msg = lazy TodoChildMessage.fromSlice(in.body); |
There was a problem hiding this comment.
I'm not sure, but I think the else branch in the match below may not be reachable as written. Since TodoChildMessage = Identify is a single-variant union, lazy TodoChildMessage.fromSlice(in.body) should throw on any body that doesn't parse as Identify - including an empty body, since the opcode parse fails first
If the intent is to ignore empty top-up messages, the empty-body check probably needs to happen before the lazy fromSlice call for instance
fun onInternalMessage(in: InMessage) {
+ if (in.body.isEmpty()) {
+ return;
+ }
val msg = lazy TodoChildMessage.fromSlice(in.body);it definitely worths double-checking against actual Tolk semantics
| match (msg) { | ||
| DeployAnother => { | ||
| var storage = lazy TodoParentStorage.load(); | ||
| storage.numChildren += 1; |
There was a problem hiding this comment.
minor point: numChildren increments before the send, and the send uses SEND_MODE_IGNORE_ERRORS. If the action fails to queue, the counter still bumps, so the next deploy uses seqno = N+2 and leaves a gap
absolutely not a bug if contiguous numbering doesn't matter, but might be worth a sentence in the prose or a short comment in the sample so readers don't assume sequence numbers are guaranteed dense :)
|
To fix the formatting issues:
Alternatively, a maintainer can comment /fmt in this PR to auto-apply fixes in a new commit from the bot. |
2 participants
closes #500