Recently, I found quite interesting bug in the node code (it h | TON technical overview

Recently, I found quite interesting bug in the node code (it has already been fixed). TVM can effectively create and handle objects with high nesting levels. However, serializing such objects into a text representation can take "infinitely" much space.
Here, for example, is the code that generates tuples with a high nesting level (it costs approximately 180 gas per iteration):

(tuple) wrap2tuples (tuple x, tuple y) asm "PAIR";
(tuple) empty_tuple () asm "PUSHNULL";
(tuple) tuple_bomb(int level) {
int current_level = 0;
var bomb = empty_tuple();
do {
current_level += 1;
bomb = wrap2tuples(bomb, bomb);
} until (current_level > level );
return bomb;
}

Accordingly, if we generate a tuple with a nesting level of, lets say, 100 and can force the node to transfer it over the network or write to disk in serialized form, the node will crash. Note, that in a non-serialized representation this tuple requires only 101 objects to be stored, since although there are 2**100 leaves in the tuple, all these leaves are the same.

One of the case where this bug could crash a node is the usage of runmethodx, a special light server method that allows you to run the contract's get-method on a light server and receive only the result with proofs on the client (this is useful when the contract has too much storage to transfer all of it to the client and execute get methods locally). If you generate a contract, with get-method which returns a tuple with a high nesting level , then the light server will crash in an attempt to allocate memory for storing the result of the method. I want to thank guys from Everstake.one (they are staking grams and have a pretty cool system for monitoring the node behavior ) for helping me in testing this bug.

Another way to use this bug is based on the fact that by default, debug opcodes in the node were not disabled and debug was written directly to stder at any verbosity level. When I discovered this, @Skydev immediately suggested spamming the logs with debug https://github.com/ton-blockchain/ton/issues/246 . This method works and may clog the entire disk over time, however, dumping a nested tuple is much more efficient: a single call with a sufficient nesting level can eat any disk.