Comparison Of Systems Doing Contracts

I'm trying to understand the differences and commonalities among various systems enabling electronic contracts (building it here).

What I can't figure out: what exactly is an "Ethereum Address"? How do I address an Agent in Ethereum and how do I check that the address obviously belongs to the addressee?

Related: what's a realistic frequency for transactions for Ethereum Agents? Range is enough: more like one-per-second (interactive) or ten minutes per transaction (batch and come back later)?

Best Answer

Answers

  • aatkinaatkin Member Posts: 75 ✭✭
    As I understand it an ethereum address either represents a human user's wallet *or* it can represent a smart contract on the blockchain. When you send ether to an address, that is basically the destination. If you want to see if an address is owned by a person you might consult a registry that links the address to an email, a person's name or the description of a smart contract.

    The blocktime on ethereum is currently approx. 1 minute. The mining algorithm has not been finalized, so this may change. @vitalik‌ has a blog post about this and how it might be reduced to approx. 12 seconds.
    So from off-chain you can read as often as you like but you can only write to it in blocks, so if you write a value to the chain and then change it, it'll take about 1 minute.

    Some smart contract platforms to compare would be: Bitcoin scripts, ethereum, open treansactions, Ripple/Codius and stuff Nick Szabo did in the 90s with his E lang. (I think).
  • jfwjfw Member Posts: 12
    aatkin said:

    As I understand it an ethereum address either represents a human user's wallet *or* it can represent a smart contract on the blockchain. When you send ether to an address, that is basically the destination. If you want to see if an address is owned by a person you might consult a registry that links the address to an email, a person's name or the description of a smart contract.

    What I'm after is a slightly different question: How do I verify the address/identity mapping is correct. So far I understand that there ought to be some kind of "self-sealing" property, which enables the proof. Like in Ricardian Contracts.
    aatkin said:


    so if you write a value to the chain and then change it, it'll take about 1 minute.

    Great to know. (That's horribly slow, isn't it? With Askemos/BALL we reach slightly more than one transaction per second!)
  • jfwjfw Member Posts: 12
    Jasper said:

    For instance if you have a crowdfunder you need to check 1) at the address there is infact a crowdfunder, 2) the limit is infact as advertised, 3) it pays out to the right people/DAOs when it finished. That is assuming that the crowdfunder is based on already trusted code(reviewed etc.) and those are just the parameters.

    Thanks. I conclude at this point that the concept of self-sealing identifier (google "Ricardian Contract" etc.) is not present in Ethereum.

    Is this true? (That would be a killer.)
  • JasperJasper Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Though phishing looks like it is possible, i dont think it is killer because there are infact more ways to detect phishing/impersonation. On the internet it basically is DNS and certificates. On Ethereum you can use both of those and redisplay the contracts and look at the contract. So if it isnt killer on the regular web, it shouldnt be on Ethereum. (assuming those things are put in place, of course!)

    Note that public-private keys still work just like bitcoin, and infact a blockchain helps against MITM, because the pubkeys are visible on the blockchain, and MITM involved putting your public-private key inbetween.

    The worry here is that the Ethereum contract is not what it is claimed to be. Basically, to say it in a way that blames the people, it is about people not reading their contracts. But of course you want to give them the tools to not make that mistake. I havent read it entirely, but most contract would satisfy this.
    Our innovation is to express an issued instrument as a contract, and to link that contract into every aspect of the payment system. By this process, a document of some broad utility (readable by user and program) is drafted and digitally signed by the issuer of the instrument. This document, the Ricardian Contract, forms the basis for understanding an issue and every transaction within that issue.
    Note that it doesnt solve regulatory pressure, although the contract would do its own thing regardless of what the authorities do, there may be procedures to take other assets, and/or taking people involved hostage otherwise. In the Netherlands, it is literally called that.(dunno about other countries)

    The "The Ricardian PKI Delivers Clarity" is what the self-sealing thing is? Afaict what they mean is that some guy at the start signs it and you get a whole chain of signatures leading to any contract in there? But you still need there are public keys of the parties to check that the signatures belong to those parties? If there is a service that you trust that links public keys to real world identities, you could easily tie H("Jasper den Ouden 9-8-1984 Eindhoven, The Netherlands") to my public key, so you can tell it is me. Alternatively, something like trust networks could do it. A central organization could do it with Merkle trees so it doesnt cost much space on Ethereum itself.

    It isnt in Ethereum but it is possible. In a sense Ethereum is a blank sheet.
  • jfwjfw Member Posts: 12
    edited August 2014
    Jasper said:

    Though phishing looks like it is possible, i dont think it is killer because there are infact more ways to detect phishing/impersonation.

    While you don't, I do. Actually we do.

    See, Ethereum is a little late in the field of modeling contracts. Unfortunately it seem to sometime ignore fifteen years of prior science.

    However it might come up with alternative solutions to the problems we solved. Different solutions result in different pros and cons and thus different strength.

    That's why I'm working at this comparison. I want to learn what ethereum could be good at. The web is no good for doing *real* contracts; please don't defend a half backed solution for not being worse than the worst. Pishing is a problem, fraud is a problem.
    Jasper said:

    Note that public-private keys still work just like bitcoin, and infact a blockchain helps against MITM, because the pubkeys are visible on the blockchain, and MITM involved putting your public-private key inbetween.

    Well, the block chain is a "consensus protocol", isn't it? So is byzantine agreement. Both are there to provide a trustworthy audit trail.

    There we are looking into the pros and cons of the approaches: A) the block chain paradigm only mitigates the Sybil attack, byzantine agreement solves it [I'd vote for the latter] B) the block chain comes out really, really, slow, while byzantine agreement allows interactive use (we even run fuse over it) [I'd vote for BA again] C) the block chain forms an open-join network, while byzantine agreement ensures close control.

    In the (C) case it depends on the needs at hand. open-join means everyone can just participate and there is no such thing like a ban. This can incur privacy issues. So often the "full solution" of using BA is better. Just not when it is your goal to have a network open to join to everyone!

    Askemos was designed after the model of the legal system underlying a constitutional state. That's why we went with byzantine agreement. Including the possibility to install courts and judges to coerce rough humans. Though nothing else in the concept would have to change if we switched to block chain.

    As we are at it, here one more question I'm not completely sure about so far: where are "contracts" actually stored and executed in ethereum? Who can extract, trace etc. them?
    Jasper said:

    I havent read it entirely, but most contract would satisfy this.

    Maybe it's a good idea to read the rest soon. ;-) The interesting thing here is that two independent research efforts lead to the same result. This is usually a sign that something is really important.

    We require such a proof build in. Otherwise I'm seeing the system doing a lot, but not handle contracts. (It does not help to just term something a contract; a judge must be able to determine what the contract is all by himself/herself.)

    Since you are from Netherlands I guess you read German? This German lawyers opinion was once sponsored by a Prof. of ethics who found the Askemos concept a great match to model our social/legal system. It comes to the very same conclusion that you really, really want such a self-verifying identifier. It really shifts the onus to the other party. You can't do that with a block chain or signatures based on secret keys etc.
    Jasper said:

    Note that it doesnt solve regulatory pressure, although the contract would do its own thing regardless of what the authorities do, there may be procedures to take other assets, and/or taking people involved hostage otherwise. In the Netherlands, it is literally called that.(dunno about other countries)

    I don't understand what you mean by "solving th regulatory pressure".
    Jasper said:

    The "The Ricardian PKI Delivers Clarity" is what the self-sealing thing is? Afaict what they mean is that some guy at the start signs it and you get a whole chain of signatures leading to any contract in there? But you still need there are public keys of the parties to check that the signatures belong to those parties?

    I don't feel qualified to answer this question. It also never became relevant to our work.
    Jasper said:

    Alternatively, something like trust networks could do it.

    Precisely. But a "trust network" is what the Bitcoin block chain is, isn't it? Another trust network would be a network of Askemos compatible peers.
    Jasper said:

    A central organization could do it with Merkle trees so it doesnt cost much space on Ethereum itself.

    Hm. I'd say, the block chain IS a Merkle tree.

    No: not only a central organization, also distributed networks of equal peers could do it with Merkle trees.

    Otherwise you are right: we actually run the Askemos test network from plug computers behind consumer grade DSL lines. It really does not cost as much as a block chain.
    Jasper said:

    It isnt in Ethereum but it is possible. In a sense Ethereum is a blank sheet.

    Is it?

  • CfBCfB Member Posts: 29
    jfw said:

    ...the block chain paradigm only mitigates the Sybil attack, byzantine agreement solves it...

    Could u share a link that explains how byzantine agreement solves the Sybil attack? I thought that first u need to solve the attack and only after that u can use byzantine agreement.
  • jfwjfw Member Posts: 12
    CfB said:

    jfw said:

    ...the block chain paradigm only mitigates the Sybil attack, byzantine agreement solves it...

    Could u share a link that explains how byzantine agreement solves the Sybil attack? I thought that first u need to solve the attack and only after that u can use byzantine agreement.
    I don't have a link. I thought this would be obvious: every voluntary association implements it in simple rules. The rule is usually that members vote to allow new members to join.
  • CfBCfB Member Posts: 29
    It's called "certification" and considered to be a centralized approach if u ask a passport or another ID issued by govt. A decentralized version of certification is vulnerable to sybil attacks.
  • jfwjfw Member Posts: 12
    CfB said:

    It's called "certification" and considered to be a centralized approach if u ask a passport or another ID issued by govt. A decentralized version of certification is vulnerable to sybil attacks.

    A) Certification (in the sense you're using it here, that is for "identity management") is strictly unrelated to group membership protocols. (Though there is some kind of group membership certification too.)

    B) No. Or at least only if the group has rules bordering on stupidity, e.g., automatically allowing any join request, allowing as many (or more) new members as the group already has to join at once, allowing to expel a third or more members in a single operation etc.

    If such decentral membership decision was vulnerable to sybil attacks, every company held privately by more than a single person would be.

    Note: once members are members, they *are* members. An attack is only a Sybil attack if it's executable by individuals not already member of the club. Once the are, it's called a majority decision. That's why there is the "check before allow join".

    Related question: How would decentralized certification (e.g., WebOfTrust, face-to-face) necessarily be vulnerable to sybil attacks?
  • CfBCfB Member Posts: 29
    edited August 2014
    jfw said:

    Related question: How would decentralized certification (e.g., WebOfTrust, face-to-face) necessarily be vulnerable to sybil attacks?

    Imagine there is a group of 3 of us - u, me and some other guy (Charlie). The 4th person asks via forum to join us.

    U can't make sure that it's not me nor Charlie, I can't make sure it's not u nor Charlie and Charlie can't make sure that it's not one of us.

    We can let the candidate to join and imagine that it actually was Charlie's sockpuppet. The 5th person could also be his sockpuppet. Now Charlie controls 60% of all votes and can allow to join anyone he wants and disallow to join for the others.

    See what is the problem? Now u can't use byzantine agreement.
  • IangIang Member Posts: 3
    Hi. JFW pointed me at this discussion, and now that I've struggled through the captcha inhumanity proof (20 minutes!!!) some commentary must be worthwhile.
    Jasper said:

    The "The Ricardian PKI Delivers Clarity" is what the self-sealing thing is? Afaict what they mean is that some guy at the start signs it and you get a whole chain of signatures leading to any contract in there?

    Yes, more or less. The contract is a static document that looks like a contract, and delivers a canonical hash as its identifier. That latter hash gets quoted as the payment instrument in any payment, rather than say the string "USD". So in effect, Alice signing a payment to Bob in some contract also signs up to that contract. Add some more payments and we generate a tree of hashes back to the first origin payment and all over the the original contract.
    Jasper said:

    But you still need there are public keys of the parties to check that the signatures belong to those parties? If there is a service that you trust that links public keys to real world identities, you could easily tie H("Jasper den Ouden 9-8-1984 Eindhoven, The Netherlands") to my public key, so you can tell it is me. Alternatively, something like trust networks could do it. A central organization could do it with Merkle trees so it doesnt cost much space on Ethereum itself.

    If we're talking about Alice and Bob, then sure, yes, an 'identity layer' is needed in some sense. In the early work in cryptocurrencies back in the 1990s we didn't consider this as being important, perhaps because they only got as far as working with developers who were somewhat comfortable with copying hashes of their mates' public keys around.

    However, the new wave of cryptocurrencies are more impacting on the general user base and working with hashes isn't really acceptable. In my current work I'm fielding a system based on social networking, CAcert and so forth so that people work as if they are dealing in facebook, but it is secured underneath.
    Jasper said:

    It isnt in Ethereum but it is possible. In a sense Ethereum is a blank sheet.

    It being the Ricardian Contract? -- I'm also guessing it is possible to do in Ethereum, but I'm not sure how strong it is without explicit support. Without a strong linkage from payments back to contract back to text, there is scope for trouble. Unfortunately for systems designers, these ramifications are typically seen by users (including anti-legal ones) before they are evident in design discussions, so take-up hits a roadblock around o(1000) users. Bitcoin cunningly bypassed this by not having a contract at all, an absence made poignant by altcoins.
  • IangIang Member Posts: 3
    Hi Jasper,
    Jasper said:

    The worry here is that the Ethereum contract is not what it is claimed to be.

    I think the precise question I would like answered is, "Is the Ethereum smartcontract a contract as understood at law?" I think that's an open question; as you say, Ethereum is more a blank piece of paper as yet.
    Jasper said:

    Basically, to say it in a way that blames the people, it is about people not reading their contracts. But of course you want to give them the tools to not make that mistake.

    Yes, this is a big point. Predicting your below snippet, the way the Ricardian Contract linkage into the payment works, it more or less guarantees that the person/ software agent has the contract. This works by making Ricardian Contract "slightly smart" in the sense of smart contracts; there is information in there that is necessary in order to display it to the users such as decimalisation and naming.

    Without that information, the display would make no sense:
    "you have 27492 of #21ec243bea24 from #213eda23cdb6a73"
    The user needs the title out of the contract, and needs to know that 27492 is presented as $27.492:
    "You have $27.492 in Iang's prepaid dollar contract. Click here for T&C"
    So we can conclude that the user has the contract [0] at least. Whether the user actually reads it is a higher level of difficulty, but probably beyond scope for today.
    Jasper said:

    I havent read it entirely, but most contract would satisfy this.

    Our innovation is to express an issued instrument as a contract, and to link that contract into every aspect of the payment system. By this process, a document of some broad utility (readable by user and program) is drafted and digitally signed by the issuer of the instrument. This document, the Ricardian Contract, forms the basis for understanding an issue and every transaction within that issue.
    The only systems that clearly met the challenge are Ricardo and OpenTransactions by Chris Odom.

    JFW's Askemos works with contracts but this is why JFW is researching all contract offerings in the various systems -- so as to clarify what it does and is, etc. Askemos seems to have the same technological contract notion for both the master contract and for the payment contract, which is a variation I'm not as yet comfortable with.

    [0] There is a slight loophole here in that someone could invent a database of the params needed but a little bit of wider analysis reveals that as an inferior solution. E.g., distro of new contracts.
  • IangIang Member Posts: 3
    Hi Jasper, last point!
    Jasper said:

    Note that it doesnt solve regulatory pressure, although the contract would do its own thing regardless of what the authorities do, there may be procedures to take other assets, and/or taking people involved hostage otherwise. In the Netherlands, it is literally called that.(dunno about other countries)

    The Ricardian Contract was invented for bonds, which are an approximately unregulated space. One could also say that the Bitcoin world is also an approximately unregulated space. But of course, it also depends on what you mean by regulation.

    The main way in which Ricardian Contracts add to that question is that they establish themselves as contracts in the conventional sense: there are parties, there are t&c, there is agreement, offer and acceptance, and the thing can be disputed in a forum. This is somewhat in contrast to say "smartcontracts" which don't really aim in that direction...
  • jfwjfw Member Posts: 12
    Iang said:

    Askemos seems to have the same technological contract notion for both the master contract and for the payment contract, which is a variation I'm not as yet comfortable with.

    "Technological contract notion" is not applicable to Askemos but rather to the implementations. Askemos establishes a semantic model for interacting agents and a language to specify operations. A "technological" equivalent would be the DOM in W3C's world.

    The minimal core of the language has only seven operations. (There are eight more to make it practical here.

    Using this language we can express creation and behavior of objects. Be them active agents, messages or contracts. At that level you are right: we use a unified notion of "objects". In practical terms this equates to saying: "both, the master contract and the payment contract are stored in a file each".

    If I want to create a Ricardian Contract, which qualifies as a bond, I have to create an object meeting additional constraints.

    There is an interesting property in the definition of how identifiers in Askemos
    wrt. Ricardian Contracts: the identifier of a freshly created object is canonical hash of the newly created object.

    However there is more required to specify:

    * an update policy. This is implicit in Ricardin Contracts: since the hash must always match, there is no update possible. Askemos is more general here, we have to include a statement saying so with every contract. (For active agents, we have to specify a different update policy, but such an active agent would no longer be a contract at all in Askemos terms.)

    * an access control token. This controls which agents are "legally" entitled to access the object.

    * a list of "notary peers". (In practice this is initially implicit). These (any only these) peers participated in the creation of that and maintain their state in ongoing byzantine agreement. In case of Ricardian Contracts: maintain their constant integrity. For active agents, e.g. the representation of a user account, these follow the code specified in the update policy to calculate the new state of the object. (At which point agents may choose to add or remove peers from the set if permitted per update policy.)

    To specify a bond one would have to write a document holding t&c and create an object, which is immutable (update policy) and public readable.

    The payment message would be a similar object, just readable only by the addressee.
  • jfwjfw Member Posts: 12
    CfB said:

    jfw said:

    Related question: How would decentralized certification (e.g., WebOfTrust, face-to-face) necessarily be vulnerable to sybil attacks?

    Imagine there is a group of 3 of us - u, me and some other guy (Charlie). The 4th person asks via forum to join us.

    U can't make sure that it's not me nor Charlie, I can't make sure it's not u nor Charlie and Charlie can't make sure that it's not one of us.
    On this ground I would not let the 4th person join. Doing so would be a stupid protocol to follow.
  • CfBCfB Member Posts: 29
    jfw said:


    On this ground I would not let the 4th person join. Doing so would be a stupid protocol to follow.

    Right, and here we see that byzantine agreement can't be used without solving Sybil attack problem previously.
  • jfwjfw Member Posts: 12
    CfB said:

    jfw said:


    On this ground I would not let the 4th person join. Doing so would be a stupid protocol to follow.

    Right, and here we see that byzantine agreement can't be used without solving Sybil attack problem previously.
    Yes, without a reputation system, you can't use byzantine agreement. So my wording was a bit unfortunate. I'd better written a longer version: byzantine agreement is not vulnerable to Sybil attack as block chain is, because it deploys some reputation system (a priori). Proof-of-work still mitigates the Sybil attack vector only to the extent that the party controlling 51% hash power wins.

    I'd still rather check a reputation system than rely on anon.
Sign In or Register to comment.