Hacking the anti-cycle mechanisms... possible? Would allow a 100% decentralized cron daemon.

fivedogitfivedogit Member Posts: 21
edited September 2015 in Solidity
When compiling a Solidity contract, if you try to instantiate a version of the contract from within the contract's constructor, you get:
Internal compiler error: Compiled contract not found.
If you break it into two contracts that instantiate each other, and then try to compile, the second (from the top down) will succeed (as it knows the one before), but the first will fail (because it doesn't yet know about the other contract) with the same error as above. Hence, the circuit can never be closed.

But I had a thought: Couldn't you "force-compile" a bytecode version of a cyclical contract (one that instantiates itself in the constructor) and then publish it to the blockchain? Or maybe you could publish a kosher contract like you'd normally do, but the contract contains a bytecode string of itself so that it can self-replicate.

Why would anyone want to do this?

One huge benefit would be a cron-like daemon. If you could create a contract that creates a new version of itself on each new block, then a list of jobs to be executed by block number could be passed from contract to contract, executing on the given schedule.

(Contracts using this mechanism would merely tell this block head crawler which block they want a transaction to happen on, give it the ether/gas to do it and tell it how to do it. Once the cron-like block head crawler calls the function of the requesting contract, it could then make a new request to do it again on block.number + 10 blocks, and so on.)

Side question, why can't contracts self replicate? What's the concern so long as gas prices are paid?

And a noob question: Can contracts be re-infused with new gas after creation?


  • chrisethchriseth Member Posts: 170 ✭✭✭
    It is not possible to have cycles of contracts creating contracts, e.g. a contract cannot create a copy of itself using present solidity code and the "new" operator. The reason for this is that whenever you use "new", the binary code of the contract you create will be part of the binary code of the creating contract. If that creates a cycle, there is a contract whose code includes its own code, which is not possible.
    There is a workaround using the "code" opcode, but that is not yet available for solidity and also creates problems because at least the constructor part would have to be duplicated.

    In general, this is also possible without something like a "code" opcode, but a bit more complicated. For anyone interested in the deeper mathematics behind that:
    As a corollary of Kleene's recursion theorem, any Turing-complete language has a program that can produce its own source (or byte-) code. Such programs are called Quines.
  • sillytunasillytuna Member Posts: 38 ✭✭
    I guess this is a bit of an aside, but 'back in the day' we used to mix C and asm, sometimes in the same src file.

    Would it be possible, if at the dev's risk, to allow us to do the same thing from Solidity? This may help work around some quite understandable language limitations.
  • chrisethchriseth Member Posts: 170 ✭✭✭
  • sillytunasillytuna Member Posts: 38 ✭✭
    Great news! Time for me to learn a new assembly language. Haven't done that since Z80 on the gameboy :)
Sign In or Register to comment.