Tolk is a fork of FunC, designed to address practical issues in TON smart contract development. Tolk aims to simplify the development process, support seamless ABI generation, and maintain zero overhead. Building on the low-level features and performance advantages of FunC, Tolk introduces several improvements, including refactored semantic analysis, an upgraded type system, clearer error messages, support for generics, and the introduction of a boolean type.
Tolk elevates semantic analysis from the low-level implementation of FunC to the AST (Abstract Syntax Tree) level. This allows the compiler to catch potential logical errors earlier. For instance, syntax errors and type mismatches can be identified during the compilation phase rather than causing unexpected behavior at runtime.
Tolk transitions from FunC’s Hindley-Milner type system to a static type system, enhancing type checking. For example, the following Tolk code snippet illustrates type declarations and checks:
import "storage.tolk"
fun loadData() {
ctxCounter = getContractData().beginParse().loadUint(32);
}
fun onInternalMessage(msgValue: int, msgFull: cell, msgBody: slice) {
var cs = msgFull.beginParse();
var flags = cs.loadMessageFlags();
if (isMessageBounced(flags)) {
return;
}
...
}
get currentCounter(): int {
loadData(); // fills global variables
return ctxCounter;
}Tolk provides more comprehensible error messages, especially for type mismatches. For instance, if a developer attempts to assign an integer to a boolean variable, the compiler will immediately report the error.
Tolk introduces support for generics, allowing developers to write more versatile code. This reduces code redundancy and lowers the risk of vulnerabilities caused by repetitive code. For example:
<T> T genericFunction(T value) {
return value;
}Tolk introduces a boolean type (bool), replacing the integer representation in FunC. This reduces the likelihood of logical errors in conditional statements.
The TVM (TON Virtual Machine) offers a rich set of instructions, including arithmetic operations, bitwise operations, data comparisons, and handling of tuples and lists. The complexity of these instructions can lead developers to overlook potential security issues. For example, improper bitwise operations may result in unexpected numerical overflows or underflows.
The gas model of TVM requires developers to pay for computation, storage, and message forwarding. Insufficient gas management can lead to resource exhaustion attacks. For instance, attackers may send a large number of transactions to deplete the contract’s gas, causing the contract to fail to execute properly.
Tolk retains some low-level features of FunC, such as the dependency on the impure keyword. Forgetting to use impure can lead to unexpected behavior.
Comments in Tolk serve not only as annotations but also as functional programming constructs. This dual role can cause confusion. For example, developers might embed complex logic in comments, reducing code readability and maintainability.
Code review is a crucial step in ensuring the security of Tolk smart contracts. By manually reviewing the code, potential logical errors and security vulnerabilities can be identified. For example, review the following Tolk code snippet:
() send_money(slice address, int amount) impure {
var msg = begin_cell()
.store_uint(0x10, 6) ;; nobounce
.store_slice(address)
.store_coins(amount)
.end_cell();
send_raw_message(msg, 64);
}During the review, ensure the correct use of the impure keyword and the proper construction of messages.
Automated tools, such as static and dynamic analyzers, can help identify common security issues.
Fuzz testing provides random inputs to test the behavior of smart contracts. Tools like AFL and libFuzzer can uncover unexpected behavior in contracts when faced with unusual inputs.
Developers need to explicitly organize data within smart contracts. Failure to do so could result in misinterpretations and unpredictable program behavior, comparable to assembling furniture with incomplete instructions.
Tact’s strict address format has inconsistencies with existing standards, such as TEP-74, which could result in failed transactions or lost tokens, similar to sending a letter to an incorrect address.
While the TON blockchain avoids vulnerabilities like reentrancy, its unpredictable transaction order could enable attackers to exploit timing differences, creating vulnerabilities akin to man-in-the-middle attacks.
Improper estimation and control of gas usage by developers can cause transactions to fail midway or potentially drain funds from a contract
Avoid directly manipulating low-level data structures (such as Cell and Slice). Using Tolk’s high-level abstractions can reduce errors.
Ensure the correct use of all keywords and comments to avoid security issues caused by misunderstandings.
Ensure that smart contracts do not fail due to insufficient gas in extreme cases.
Ensure the readability and maintainability of the code.
Tolk builds on FunC with several improvements, significantly enhancing development efficiency and code readability. However, Tolk’s low-level features and complex instruction set can still introduce potential security issues. Developers should follow best practices, including code reviews, automated tool usage, and fuzz testing, to ensure the security of smart contracts.
By implementing these measures, developers can significantly reduce the security risks of Tolk smart contracts and build more secure and reliable decentralized applications.
We focus on cyber Security and Threat Detection and Response, and provide industry-leading Cyber Security Solutions, which can completely cover all cyber security requirements of all kinds application scenarios.