Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Categories
- 17.2K All Categories
- 9.4K Mining
- 569 Pool Discussion
- 342 Promotional
- 1.4K General Project Discussion (non-technical)
- 479 Education
- 804 Protocol and Client discussion
- 167 web3-js
- 29 Whisper
- 16 Swarm
- 3 RLP
- 299 IoT & Hardware
- 1.2K Smart Contracts and Dapps
- 28 Serpent
- 357 Solidity
- 645 Projects
- 1.2K Reference clients code and builds
- 249 Eth & AlethZero- Cpp Implementation
- 469 Geth - Go Implementation
- 241 Mist
- 15 Node.js Implementation
- 36 Python Implementation
- 49 Mix
- 36 Other Implementations
- 169 Meetups
- 40 Other Events
- 223 Jobs & Skills
- 258 Press and Articles
- 75 Audio/Video
- 295 Ether Sale
- 1.2K Other Languages
- 94 Chinese
- 254 German
- 33 Italian
- 110 French
- 3 Hebrew
- 42 Japanese
- 75 Portugese
- 46 Romanian
- 184 Russian
- 227 Spanish
- 47 Turkish
- 125 Watercooler
Comparison Of Systems Doing Contracts
jfw
Member Posts: 12 ✭
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)?
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
-
Jasper
Eindhoven, the NetherlandsPosts: 514 ✭✭✭
To actually see if the address is the actual contract you want to talk to, i think you need to check if it has the actual contract with the right relationships to things that the person advertising it says it has. There is probably a lot of room for software to help this along, one of those might be the . 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.
I think in practice, well you'd go around looking for info about it, or look what discussions say about it. Of course if you go by discussions you need to weed out shills and incorrect arguments both for and against things. Edit:... forgot to mention, the browser can show information in a nice GUI based on contract data. A phisher could still bake up a gui that doesnt present the data correctly, you could fight that with certifying(preferably a system anyone can start), reputation systems(sort of the same as certifying), and having sets of other GUIs to interact with the same contract.Post edited by Jasper on
Answers
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).
Is this true? (That would be a killer.)
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.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.
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. 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]
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? 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. I don't understand what you mean by "solving th regulatory pressure". I don't feel qualified to answer this question. It also never became relevant to our work. 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. 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. Is it?
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?
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.
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. 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.
Without that information, the display would make no sense: The user needs the title out of the contract, and needs to know that 27492 is presented as $27.492: 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. 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.
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...
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.
I'd still rather check a reputation system than rely on anon.