Extrospection is awesome, don't kill it

The latest blog post states that the EXTRO opcode was removed in order to create a market for data feeds. That strikes me as short-sighted, considering the advantages of permitting contracts to directly inspect each other's source code. That ability would open up a very wide set of behaviours; in particular, co-operation with a correctly formed 'stranger' becomes possible, even when neither contract contains knowledge of the other at the time of its creation, because their behaviour becomes known and deterministic. There's a lot of interest in this sort of thing on the rationality forum lesswrong.com; I was particularly excited to see extrospection in Ethereum because there are very few other contexts where the requirement of mutual knowledge of source code is provably satisfied. Would anyone else like to see EXTRO return?


  • StephanTualStephanTual London, EnglandMember, Moderator Posts: 1,282 mod
    Hi Topynate, interesting topic, do you have a link to the lesswrong thread where this is discussed? Thank you.
  • jamtodayjamtoday San FranciscoMember Posts: 13
    @topynate? I am not completely convinced it is needed along with the new POC 3.5 opcodes but I could very well be wrong and I think it is probably worth reinstating if there is interest. So count me in.
  • topynatetopynate Member Posts: 4
    edited March 2014
    @Stephan_Tual They (we) have been talking about this literally for years, often in the context of the Prisoner's Dilemma; an early post is at http://lesswrong.com/lw/do/reformalizing_pd/ and the tournament proposed there was actually done at http://lesswrong.com/lw/hmx/prisoners_dilemma_with_visible_source_code/, but there must be dozens of posts of various levels of technical complexity. There's a whole decision theoretic aspect to this that you can dip your toe into at http://wiki.lesswrong.com/wiki/Timeless_decision_theory if you're so inclined.

    @jamtoday: If so, then great! I'm not sure that CALL/RETURN would be enough, though - a contract can RETURN whatever the hell it likes, whereas EXTRO always evaluates to the actual content of a storage location. If EXTRO messes up the purity of the new architecture, then perhaps a new return type that is guaranteed to contain an honest representation of the contract's internal state is the solution. This would also mean that contracts retain control over which other contracts they share data with.

    Edit: Now I think about it some more, it would be essential that the new 'verified RETURN' terminated execution of the contract immediately, or else a malicious contract could shuffle its state around to deceive another contract as to its function. As to the associated CALL, it should be able to request a range from the contract's storage - but I think that's already supported, as a CALL can send data as input.
    Post edited by topynate on
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    If there is a standard regarding some exchange of information, two parties only need to know about the standard, so strictly speaking, they can be strangers otherwise. And a full node can pick data right out of the blockchain and send it to contracts in a transaction. (trustfully, although you could give parties a stick)

    However, that is a nitpick; reading your first link, it is specifically about contracts reading the other contract? Sounds neat to me.

    A contract can return whatever it likes but, there is consensus over the code and the execution. Important point about ethereum, but again a nitpick; without EXTRO, contracts are second class citizens regarding that; no access to the consensus about what the code is.

    So what you mean with 'verified RETURN' is that you ask a particular contract.storage[N], and the contract may accept or deny, but never falsely report? Obviously, it would either have to return the value before running, or be disallowed to change any state; It may lie by contract.storage[TMP]=contract.storage[N]; allow_access(N);
  • topynatetopynate Member Posts: 4
    edited March 2014
    @Jasper That's roughly what I'm aiming for with 'verified RETURN', but I wasn't thinking along the lines of 'caller requests access to location; receiver chooses whether to allow it'. Specifically, I think it would be a good idea to add a VERIFIED_CALL opcode for requesting a verified state, and add a VERIFIED_RETURN opcode that when executed returned a truthful range of storage locations, along with the bounds, and then immediately terminated execution. Executing RETURN in the context of a message from VERIFIED_CALL or executing VERIFIED_RETURN in the context of a message from CALL would end execution without returning a value.

    This would be enough to stop 'lying' contracts, as they could provably put themselves into a state in which their future behaviour was provably honest. I'm only relying on the contract code living in storage and execution starting at index 0, here. Then the calling contract could take a hash of that state or a masked-out version of that state, and check it against a stored hash.

    The return value would need to go somewhere; probably the simplest thing would be to put it on the stack with the bounds at the top, and let the caller deal with the resulting mess. It should all be hidden in the HLL anyway.
  • VitalikButerinVitalikButerin Administrator Posts: 84 admin
    If there is an opcode for getting the _hash_ of a contract's code, allowing contracts to voluntarily prove that they have certain code, would that satisfy your concerns?
  • topynatetopynate Member Posts: 4
    edited March 2014
    That would probably cover at least 90% of practical use. It would certainly be simpler to deal with a single value than an arbitrary-length array dumped onto the stack. All the information specific to that particular contract could be kept in storage locations not included in the hash.

    It does make it harder for a contract to do dynamic analysis of another contract's code, but that would see pretty minimal use anyway, I think.

    Edit: to reduce the returned data to a single hash, the caller should be able to request that the hash be taken within certain bounds as well.
    Post edited by topynate on
  • chris613chris613 Member Posts: 93 ✭✭
    If I understand correctly, this would allow contracts to take an input that names another contract to call, and then verify that the contract they are being asked to call conforms to some exactly specified code. I guess I'll have to go read the LW threads to see just how helpful this is.

    Dynamic (or even static, for that matter) analysis of code being done in-blockchain just seems crazy to me, but it could be done by having the volunteering contracts implement a call that returns their entire source code, which you can validate against the hash before starting your analysis. When it comes to dynamic analysis (sandboxing another contract's code to analyse its behaviour), that's just super bananas to do on the blockchain. I'd rather have 1000s of nodes each running different branches of that analysis in a feature rich execution environment as part of a conventional high performance cluster, whereas ethereum has 1000s of nodes each running the same branches of analysis in a single thread in a very restrictive execution environment. You're not going to get any emergent-take-over-the-world-super-AI from THAT! ;)
  • giactgiact Milan, ItalyMember Posts: 5
    Wouldn't any form of dynamic analysis of a contract's code eventually lead to an "attacker" exploiting the Turing's halting problem to make your contract run into an infinite loop while it tries to analyze his maliciously crafted contract?

    Given the current state of the protocol (gas and gas price), an "evil miner" could craft contracts so that when analyzed by your specific contract, they run into an infinite loop, thus transferring the caller's entire transaction fee into the miner's pockets, for free (note: since the "evil miner" already knows about the infinite-loop-bomb he can even skip the whole computation when he sees it's being performed by your contract trying analyzing his).

    Therefore I think that providing just the hash of a contract's code covers ALL cases that you actually WANT to implement, from a security standpoint.
  • LukeDLukeD Member Posts: 23
    edited May 2014
    Taking out the ability to read another contract's code is extremely short sighted. Have you considered how Object Oriented programming can be implemented yet? Creating a derived type isn't possible without direct code inspection! Even allowing programs to get a hash of another contract's code is not enough. That would allow a fairly limited form of type checking, but not the ability to implement inheritance.

    You're crippling Ethereum and making it that the most common paradigm in programming cannot be written!

    @giact: Dynamic Analysis of code is always problematic, but Static Analysis is easy and should be allowed as it is necessary for some very basic programming practices.
Sign In or Register to comment.