As the article briefly suggests, this problem can be completely avoided if every method has no more than one external call and always puts it last.
I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them call a withdraw function.)
It seems like there are quite a few pitfalls to avoid just in writing these contracts, and they aren't obvious things in many cases. This seems incredibly dangerous, given what is at stake when a bug is included in a contract.
Is there any form of auditing that contracts can go through to not have these pitfalls?
I wonder how many of them are still undiscovered...
There's both an active developer community willing to help for free, and professional auditors you can pay. There are also people talking about a NASA-style bugs/best practices database at some central location.
People are realizing that this needs to be developed like safety-critical software, not like fast-moving startup websites. But I would say it's not as scary as, say, developing software for aerospace or medical applications.
And what really helps is that you can do a lot with very little code. I think all of my contracts are under five pages. I don't think we're ready for big complicated contracts, but there's a lot we can do with simple little contracts.
Five pages? I thought these things were meant to be shorter than plain-English contracts. I draft and review contracts daily and five pages is long for basic things (employment, NDAs, IP transfer etc).
He is correct in stating that it is code v. english, apples v. oranges. But I was under the impression that the whole point of using code was to explain something in more concrete and definitive terms. If doing so takes more words, more abstract word, with more oppertunity for bugs and loopholes, then what is the point?
Smart contracts are not an alternative for things like employment, NDAs, and IP transfer. But how long would your contract be if you were setting up a currency exchange?
And how much software would you have to write in addition to that? On Ethereum the back-end software and the "contract" are the same thing, since the software enforces the terms.
Natural languages like English imply much more through context, and trade precision for succinctness. This is less true for legalese but still the case. Computer programs need to be explicitly defined and precise because there is no intelligent interpretation.
It would be nice if you could dry-run each execution of the contract and verify it passes a series of tests. It seems to me that regardless of how these contracts are written, you should be able to verify the behavior.
There is no contract simulator AFAIK, but you can deploy contracts to a test network or your own private test network. The benefit there being it's cheaper from a Gas perspective, and you don't pollute the main network.
Aside from running on a test chain there's the Mix IDE, which basically does have a simulator, and an actual debugger. So far it's kinda unstable and tends to crash, but I like it a lot anyway.
If this code style is an absolute requirement for the code not to be exploited, it should be probably be built-in in the language specification itself.
> this problem can be completely avoided if every method has no more than one external call and always puts it last.
Actually, it's a bit more nuanced than that. If you have methods that make external calls--even if it's the last thing they do--you still have to ensure that all your externally-callable methods do not share state with the methods that make external calls. Restricting where and how often you do your external calls isn't sufficient, since that last external call at the end of your method can turn around and call other methods in your contract (which can alter the contract's state, if you're not careful).
I'm not sure Haskell's type system is sophisticated enough to be relied on to prevent the kinds of problems The DAO ran into. As I understand it, one of the bugs boils down to recursive calls between two side-effecting functions, which seems like it would probably be just as possible in a parallel-universe Ethereum based on Haskell.
Hmm, so the DSL needs to enforce some kind of contract and limit scheme, like that Ada dialect that the aerospace guys occasionally bring up. I bet they have decades of research that the next DAO project devs should familiarise themselves with.
So one contract can call a function in another contract, in the middle of their transaction:
if (_recipient.call.value(_amount)()) { // vulnerable
That's inherently a scary feature, and it was exploited.
Etherium's "Solidity" suffers from the desire to have it be a general-purpose computer. It should have been if-then rules, or a logic tree, or a decision logic table - a finite representation of business logic subject to exhaustive case analysis. Contract executions should have been atomic transactions - either everything commits, or everything gets rolled back. Stack overflow and running-out-of-gas terminations are inherently trouble.
Etherium needs to go back into the shop for a redesign. At least we found out early that this isn't going to work.
The problem with a redesign is that the only way you're going to get a reliable design involves a lot of formal verification, which is a rare skill and time-consuming to perform.
Whereas the cryptocurrency space is a startup environment: there's huge pressure to launch first so that you can get the money that people are begging to throw into untested speculative finance systems. And the refusal to countenance human control or any of the normal forms of accountability - these things are designed out of the system deliberately - means that there's going to be a long, slow, expensive period of designing them back in.
Hehe, that's even better. But it is the essence of the matter. If you put $100M in a bucket you've just incentivized the worlds bad guys to audit your production in order to figure out how to open the bucket to get to the loot.
And this goes for all of commerce, which is an important realization: security is not an all-or-nothing proposition, it is an economic affair. Whatever you wish to secure, you can expect to expend a reasonably constant fraction of that on the act of securing it. So if you wish to secure $100M you will have to do a much better job than if you wish to secure $10M or $1M, just like you're going to spend more money on the lock for a $1k bike than a $25 junker.
When DOA ended up being over-subscribed they should have immediately yanked the emergency brake because whatever plans they had would end up being moot by virtue of storing more money in the bucket than they originally planned.
Their security measures would by definition not have been up to the task because they had planned to secure a much smaller amount. Either that or they were ridiculously over-confident.
"This impacts all contracts on Ethereum, not just the DAO. This is an issue with Ethereum’s JavaScript-like programming language (Solidity)."
No it doesn't, no it's not. It affects contracts that use this functionality with arbitrary untrusted contracts (which is a bad idea), and most contracts just don't use this functionality at all.
So it impacts the DAO and potentially impacts other deployed contracts (we don't know yet).
It's an issue with Solidity because it doesn't even do static analysis to give the programmar a warning.
It's not that programmers actively avoid doing this or are explicitly warned to not do it. When real money is at stake the language design needs to be a lot more careful.
So you think it's safer if used among "trusted contracts"?
Even if you wrote all the contracts that are interacting like this yourself, this is an immense source for bugs. As anyone with some experience in concurrent programming or OOP can tell you.
Communication between contracts should have been defined and done via channels.
Yeah, all this shadenfreude from people who (wrongly) predicted ethereum would never work, and who want to feel vindicated, is predictable but frustrating.
Honestly, I was in awe by r/bitcoin's reaction to this whole DAO debacle. I thought that the whole Mt Gox "incident" has taught them some empathy to people losing money but I was very wrong.
Empathy? Bitcoiners? A large chunk of them are anarcho-capitalists who measure a person's right to survive by how much money they can make, and most of the rest are in it to make themselves rich. There's a fair few who are mostly in it just because it's cool tech, but they avoid Bitcoin forums now due to the former two groups.
Note that this covers most other cryptocurrencies as well.
Isn't this just a normal data race with stateful actors? Something modified the data while A is calling B (doesn't have to be B, could be any X) in between a call and its response.
The answer to this is that mutation needs to be kept under control. Immutable data structures in mutable buckets. Locking around the data that mustn't change. Deep copy all state before calling out. And so forth.
This is basically an understood problem and I'm a bit appalled that Ethereum didn't build protection against it into their design.
It's not quite a data race, since there's nothing parallel at all. Transactions are put in a particular order and run one at a time. So it actually does have to be B that does the modification.
One easy solution is to have just one external call per method, and always put it at the end of the method. Another is to use a single mutex for all public functions of the contract, so any callbacks fail.
I don't understand "you can't assume anything about the state of the contract." Surely the contract's state is only modified by the contract's own code, which means you can assume that the state is not altered arbitrarily but only according to the rules set up by the contract. Yes, you need to be careful about external calls that make altering calls to you.
The problem pointed out in this article isn't that it is impossible to write correct contracts. The problem is that it means that it is superhumanly difficult to write correct contracts, using the current feature set and infrastructure. This is especially true in what is theoretically an actively hostile environment, which the DAO hack proves is also actually an actively hostile environment.
It is theoretically possible to call out to another contract that has the ability to make further calls safely... but how can you be sure you've done it safely?
This isn't a unique problem. It arises in imperative-based programming all the time. But what in Javascript may be a bit of a coding error that means the next page of search results didn't load this time, in Solidity it means you may lose your shirt.
Also, I'd suggest that after-the-fact "static analysis" tools don't help. It's basically the same situation that real-world computer security is in, and right now, that world is massively advantage attacker, with generally far less direct incentive to attack than a blockchain functioning directly as money does. If the static analysis tool is open enough for "everyone" to use, the attackers get to use it too, and they can use it on all contracts at once because they're all open, and they have all the motivation to do so before the proper contract owners have time to fix their contracts. Every time the static analysis tools release a new check, it's an advantage-attacker race between exploiting the new check and fixing the contracts. The attackers are going to win big, repeatedly.
A Turing-complete blockchain needs to come out of the gate nearly 100% correct on this front, just as it needs to come out of the gate nearly 100% correct on the encryption security.
I'm not sure that it is super humanly difficult. It seems likely that programming patterns, such as not using I trusted external sends at all, will emerge that any contract will need to abide by to be trusted.
If what you say is true then Ethereum is DOA, which seems unlikely to me. (I don't own any ETH.) I totally agree that it would be great to have more language based security and I've started dabbling with some stuff myself (playing with verified byte code compilation in Agda) but my basic attitude is that worse is better, these hacks are unfortunate but educational, and now we're going to see way more care in contract construction and let's hope it works out.
It might be that Solidity is going to be replaced, and it's super interesting what will come. A bunch of people are insisting that some variant of functional programming with types is necessary for correct contracts but I'm skeptical until I see an actual proposal...
And there are still people running around who think that writing code based on threads and semaphores isn't superhumanly difficult and people just need to Try Harder (TM).
At least when they're wrong, they usually don't lose millions of dollars. (But only... usually.)
I think some people are mentally modeling Ethereum as a sort of hobby thing in their head when they say things like that. I mean, who cares if my hobby static-rendering blog platform has a few bugs in it, right? But Ethereum aspires to be the foundation of an economy. Real foundations of economies have billions of dollars worth of effort poured into them. While a small set of particularly brilliant people may produce something that can run in this environment, Ethereum isn't what it would look like if they did.
I also think that people don't realize that the usual fate of a cryptocurrency is to die. Bitcoin isn't the first cryptocurrency by a long shot. Cryptocurrencies in general are not strong, robust things. I think something like Ethereum is quite likely, but there's no particular reason to believe we aren't three or four more major fully independent stabs at the problem away from a stable solution. Ethereum makes Bitcoin look like a homework problem in comparison; it would almost be beyond belief that we'd get it right the first time.
I think humans are capable of writing correct programs even in machine code, it's just tricky and requires some expertise.
I also think the EVM itself allows for other paradigms than Solidity that might make it easy to create certain kinds of contracts.
And I think worse is better is very powerful, so it wouldn't surprise me if Ethereum sticks along for a long time, like Bitcoin seems to be doing despite its flaws.
I'm not an expert in programming languages design and I've read about Etherium just a couple of days ago. But when I saw that "Solidity is like JavaScript and Python" - I was like "What? I'd pick some functional programming language for that!".
Well in theory couldn't any obscure exploit in the underlying framework (Solidity or related) be used to exploit contracts based on it? I think a comment from yesterday nailed it - that a system like this may be perfect for processing a repetitive, high volume of relatively low value contracts, wheres high value contracts may be better served by traditional systems wherein the Courts provide dispute resolution as needed. Broadly it would seem like Ethereum needs to isolate the potential for loss due to zero day exploits such that it is less than the savings realized from operational efficiency.
With all this fuss over ethereum security flaws, can someone explain to me the practical use case for these smart contracts? I just don't understand where the benefit comes in. It seems like any type of contract that would be useful requires a human to qualify the meaning of the terms since these contracts cannot autonomously measure the state of the world.
Even something as trivial as betting on sports requires deference to a trusted authority to say "this team won". What advantages does an ethereum smart contract provide over, say, some kind of trusted bitcoin escrow site?
I think the basic idea is that with Bitcoin, you sort of have to hack at it to achieve any unintended functionality. These things can and do exist in the Bitcoin world, but when you get down to it, Bitcoin is meant to be a currency; anything built on top of that is just a hack that happens to work. Ethereum and its smart contracts, on the other hand, are structured to handle these sorts of extensions by design. There's nothing that Ethereum can do that Bitcoin absolutely can't be used for in some hacky way AFAIK, but it's generally much easier to do complex things with Ethereum that aren't strictly transactions of currency.
This makes sense, but I guess I just don't see much practical utility beyond what is already achievable and less prone to security flaws with bitcoin. There just doesn't seem to be much useful code that can come out of "money as variables in a program" since just about everything related to how humans intend to distribute money hinges on the facts of the real world for which the program must rely on humans to input.
Contracts I'm working on include variants of anti-theft vaulting, blind auctions, crowdfunding, person-to-person gambling, currencies, exchanges, and a simple implementation of Bitcoin's Lightning. None of them require external data.
For those contracts that do, at least you're reducing the third-party trust to "provide accurate data" instead of "hold my funds without stealing them." To reduce trust in a single entity you can use various schemes that allow multiple independent parties to provide the data.
Or this? How does the contract ensure that the winner of the auction receives what they have purchased?
> crowdfunding
In what respects beyond simply collecting funds? How does the contract judge that the terms of the funding are adhered to or ensure that the crowdfunders receive whatever it is they are entitled to as funders?
> person-to-person gambling
Any examples? In my post I gave the example of betting on a sports game but this requires a trusted 3rd party to officiate the outcome of the game.
> currencies, exchanges
These are vague descriptions and these things have already been done by bitcoin.
I'm not trying to nitpick, but I'm looking for specific practical examples that demonstrates the potential utility of ethereum.
So this gets into the difference between the rhetoric about smart contracts, and what they actually do. Obviously a smart contract can't ensure that an auction winner or crowdfunder gets the item. At best there could be some kind of reputation system. But to enforce something in the real world, you'd have to get an actual court involved. The smart contract removes the need to have an auctioneer running the auction and handling funds, that's all.
But that still means that, for example, when I'm trying to implement a new variant on crowdfunding, I can write the whole backend in several pages of code and just publish it, instead of renting servers, administering databases, signing up with a payment provider and having to comply with its terms of service.
...which some researchers proposed for Bitcoin, saying it'd be "easy" to implement with a hard fork adding a new opcode. I implemented the same scheme in a smart contract and it took 20 minutes.
Sports betting needs third-party data, but casino games don't.
Stuff like blind auctions and gambling is somewhat constrained by the fact that Etherium applications have to be deterministic and their state information and transaction history has to be publicly visible.
- a multisignature wallet, that requires more than one person to sign off on a transaction before it can happen.
- payment schedules or any kind of transaction that does not function exactly like a one time, full size payment (payments, debt, etc).
- more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after access has been revoked
In all of the above the inputs are contained in the blockchain and therefore have no need for trusted oracles.
> a multisignature wallet, that requires more than one person to sign off on a transaction before it can happen.
This is possible with bitcoin isn't it? What does the added complexity of ethereum bring to the table?
> payment schedules or any kind of transaction that does not function exactly like a one time, full size payment
This also seems possible with bitcoin, but it's also a problem that has already been solved better by the traditional payment system (e.g. netflix debits my credit card every month, why would I use a cryptocurrency solution instead?)
> more ambitious ideas, like the Slock.it ones, involve smart locks that hold funds while granting use to a resource, and only return them after access has been revoked
Can you go into specifics here? I'm not really understanding. It sounds like you're describing a kind of autonomous collateral system, but I can't really think of any practical examples where this would be useful (without bringing human judgement into the mix).
> netflix debits my credit card every month, why would I use a cryptocurrency solution instead?
Presumably you trust Netflix enough to give them your credit card details, and you trust your credit card company enough to pay them when they present you with a list of transactions they claim you made.
That's fine for such big, entrenched players; presumably you wouldn't put as much trust in some unknown, anonymous online entity. (Although presumably trust in Ethereum isn't exactly high right now)
I suppose it depends on the product, the merchant, and the cost of the subscription. Certainly, it'd be foolish to give out a credit card to a merchant I do not entirely trust, however, it seems more risky to move cryptocurrency into a contract with a merchant I do not entirely trust (and a contract I probably don't fully understand, even if I take the time to read the code) since a credit card can protect me from fraudulent and erroneous charges that are forfeited if I opt for cryptocurrency.
This might sound funny in light of recent events, but the idea is that a smart contract requires no trust in a 3rd party as the rules are specified within the contract and the Ethereum platform guarantees proper execution of the contract.
I understand how it works, I just don't see how it is useful in this instance. How is a smart contract helpful in the case of an online subscription service like netflix? A credit card is less work because I don't have to "refill" the contract every month and it's safer because of the added protection from fraud and erroneous charges that a credit card company guarantees.
For example, a smart contract might withhold $100 from an account, and grant whoever owns the private key to that account access to open a lock. When the user is done using the resource (say, a shared car or apartment or locker), he can request his money back (minus a fee for using the resource) which would render him unable to use the resource anymore (i.e. open the lock).
Basically the equivalent of a credit card collateral on a rental, minus the credit card company.
> Basically the equivalent of a credit card collateral on a rental, minus the credit card company.
I just don't see how a smart contract is helpful here since you're still relying on the owner of the resource to relinquish your funds when they are satisfied that you have returned their property in the condition they rented it to you. Whether you use cash, credit card, bitcoins or eth the power dynamics remain the same because it's ultimately up to the owner to say "ok, everything looks good, you can have your deposit back now".
Yeah, basically any time a smart contract involves anything that isn't a digital commodity (currency or otherwise) on the same platform, you run into that kind of problem, AFAICT.
So it seems to me as well, and even when you're dealing with most kinds of digital commodities, I don't see how a smart contract is helpful. Say I bought some software from valve or microsoft or whoever; I pay (with fiat or crypto) download, install and run, if it does not function or is totally different from what is advertised, I can ask for a refund and either the merchant will honor my request or they won't, but a smart contract cannot codify this type of arrangement.
I don't want to sound like a hater, and I think as a developer it seems pretty cool that you can start receiving funds on the web without relying on a 3rd party gatekeeper, but it seems like smart contracts have pretty limited uses (not that they are useless, just very specialized)
A locker wouldn't have that problem, as there is nothing to break. Public bikes in many big cities don't have that problem either (i.e. there's no assessment of the returned bike). A smart car doesn't have to have it either (sensors in the car could detect crashes, for example, and interiors could be built to be tough, like many public cars already - see Paris' AutoLib).
> A locker wouldn't have that problem, as there is nothing to break.
There is also no need for collateral or a smart contract in this scenario.
> Public bikes in many big cities don't have that problem either (i.e. there's no assessment of the returned bike).
How does a smart contract improve over the current system?
> A smart car doesn't have to have it either (sensors in the car could detect crashes, for example, and interiors could be built to be tough, like many public cars already - see Paris' AutoLib)
How does a smart contract help?
In all of your examples a smart contract doesn't add anything to the equation because the merchant (or the merchant's automated centralized systems) already have the authority and capability to relinquish deposited funds.
>Can you go into specifics here? I'm not really understanding.
It sounds like a security deposit, of a type. For example, I had to leave one of my shoes at the front counter of a store that hosted a small gaming LAN in the back.
If that's the case then I'm confused as to where the cryptocurrency comes in. A security deposit works just as well with fiat cash as it does with cryptocurrency and in your example there is no money exchanged at all.
I just don't see how ethereum (or even bitcoin) is useful here. If you make a deposit on a rental vehicle then the deposit will be returned when you return the vehicle as it was given to you. Why is a smart contract needed?
I'm not really sure what you're asking for. If you're looking for a system capable of accepting payment without an attendant there are many. Here is just one example:
I was thinking of a system that would let you place a deposit immediately before rental (imagine a rental car in a public lot) and then automatically receive your deposit back when you are done with the car (which was possibly even left in a different lot). I'm thinking the car would use its sensor system to detect if any damage might have occurred and if not, it could trigger the return of a deposit as soon as the vehicle is locked.
Admittedly, I don't really understand the distinction of a "smart contract". I am only describing the function of the system that there was some confusion over.
Ok. What I'm saying is that the ability to accept and relinquish an automated security deposit does not require a decentralized technology such as ethereum or even bitcoin.
A machine (like the one I linked above) can accept money and dispense money at the discretion of the business rules that determine the appropriate criteria for these operations (via car sensors or whatever).
> Yes, but that requires a fixed machine (or a cash lock box on every vehicle?).
Of course not. Do it exactly like how rentals work today except in an app instead of in person. Put in your bank card info, a hold is placed on your card, when the vehicle is returned the hold is released and the service fee is charged.
In the scenario you gave, the trusted oracle never needs access to the funds. This is important for legal/regulatory reasons. This would not be possible without smart contracts.
Yes, its not 100% trustless, but its far more trustless than the alternative.
Interesting Ethereum uses the term "function" however in programming we understand a pure function to be an operation that always returns the same result given the same inputs.
I don't know anything about Ethereum, but if functions rely on external shared state then they aren't pure functions, are they?
Well, solidity is kinda javascript-style syntax and that's the keyword from javascript.
On a pedantic level, you're absolutely correct, but real-world usage generally makes 'function' equivalent to 'subroutine', hence why we have the specific term pure function to disambiguate.
Ethereum (well, Solidity) calls them methods, not functions, and everybody agrees that methods are potentially state changing procedures.
Moreover, there is a staggering amount of precedence for using "function" without implying purity, so even if Solidity did call them functions, that would be entirely normal terminology.
And, well, the entire point of invoking a contract is to effect some change to the state of the blockchain, so it would be strange to expect that Solidity methods were pure functions.
Why I used them: I was a little punch-drunk waking up, and the DAO stuff the last couple days has been a great representation of the worst basic instincts we share. I was surprised to see an informal snarky response stay positively scored. I was even more surprised to see that the emoji weren't stripped.
As for the question you actually asked, how did I? Emoji keyboard from iOS 10b1 on an iPhone 6s Plus in Safari.
Actually it's much worse, it's the equivalent of calling a function that ends up doing something totally different than you thought it would. Very reminiscent of a web bug that has since been blocked by newer browsers: parsing JSON data that ends up using a constructor redefinition exploit to execute arbitrary JS.
Given that trust is the single most critical aspect of the entire platform, why doesn't it use languages (for both the platform, and the contracts), programs in which can be easily formally verified, and for which tools for such verification already exists?
The typical solidity dev is "but mutexes cost so much gas!"
There's an optimization problem not yet sorted out here. If I were king of ethereum, (happily I'm not), I'd make a very cheap mutex support part of the eth vm and encourage solidity and serpent devs to use it as needed.
Yes, that would be a kind and fine thing to do, or at least change the cost of a specially designated bool argument to something cheap. You get one per contract, kind of thing. Or you pay on deployment.
With a mutex, an A -> B -> A call would deadlock if the mutex is the stop-and-wait or spin-and-retry sort. It would have to be a succeed-or-exception mutex, which is not a common design.
It's a code mistake by who did the DAO code. (DAO != Ethereum) It's more the equivalent of using eval in your nodejs code to evaluate some parameter received from a user. It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked.
It's a stupid code mistake, but you wouldn't say the internet is a bad idea because some website got hacked.
But if you're setting up a situation where server after server is constantly compromised because of hard to discern reasons, then yes, that is a bad idea. Having an internet is something as obviously good as electrical wiring and highway bridges. Having a badly implemented internet is as obviously bad as faulty wiring and badly engineered highway bridges.
This stuff is making Ethereum sound like it was written by people as unqualified to make such a system as a dev who would use eval in nodejs code on a user supplied string is to implement an ecommerce site.
Essentially this is the equivalent of a dev mistakely using an eval in the wrong place in a nodejs code. But all these articles are making it sound like the Ethereum team created the DAO and this issues affect Ethrereum as whole, which just isn't true.
The way I see it (continuing the simile): if you're writing something as critical as monetary transactions, everywhere is the wrong place to use eval in nodejs code. And when you're writing a dedicated language for monetary transactions, including eval in your API is just as wrong. The last part is why this issue affects all of ETH.
Solidify is a new language, specifically designed for Ethereum. If the response to contract issues like this is "but that's a known failure mode, don't do that", then that signals a problem with the language, not just the contract code.
If the response to contract issues like this is "but that's a known failure mode, don't do that", then that signals a problem with the language, not just the contract code.
It also signals a problem with the culture, with respect to the perceived amount of rigor required by the problem domain.
I dont think I would consider Ethereum a "concurrent system" in the same sense.
This functionality is there because it allows contracts to interact with each other. This allows a million different type of applications, e.g you could create a crowdfund using a gold token hold by a multisgn.
The contracts are usually trusted and their addresses set from beginning, so this is never an issue (unlike what the article implies). The DAO however allowed an arbitrary address to be used as the contract to talk to. This is flexible because it allows contracts to be update themselves, or update who they talk to, but if the contract is malicious and there is a reentrancy, then that's the issue, but again, it's the contracts fault, not the whole platform.
> This is flexible because it allows contracts to be update themselves, or update who they talk to, but if the contract is malicious and there is a reentrancy, then that's the issue, but again, it's the contracts fault, not the whole platform.
The platform is being shown to be superhumanly difficult to write secure contracts for. That's a platform issue.
Ok, but you realize that merely listing the words in the acronym does nothing to explain what it actually is. The whole ethereum "ecosystem" is a radical and new construct that very few people are familiar with.
Given that, I would even say that the name "Decentralized Autonomous Organization" is a deliberate, almost satirical, obfuscation.
When you say it's "usually used as a common term", that sounds like wishful thinking. It seems you want to take the term back and distance it from The DAO.
But new efforts like this won't call themselves "a DAO" anymore than a new airship would be called "a hindenburg".
Okay, so let me preface this with a warning. This will be an imprecise analogy! This is just meant to be an aid to understanding. Obviously, there are nuances of the DAO that don't fit perfectly into this model.
Imagine a publicly owned company. It has a CEO, COO, CFO, board, and shareholders. Most decisions are made by the chief officers of the company, and these officers are kept in check by the board of directors. Some shareholders can vote on certain decisions as well if they have the right kind of stock, but for the most part, consensus isn't really needed for most decisions. Day to day operations are handled by the COO, finances are handled by the CFO, and the CEO sort of steers the company as a whole. Most of the time, the board is hand picked to make sure that this centralization of power remains intact. In most companies, shareholders exist primarily to cash in on their own stake in the company either through dividends or by eventually selling their stock. They don't really have to make decisions most of the time, they just provide the capital. The board is there to make sure that their best interests are being catered to basically.
The DAO is almost as if you got rid of management entirely. With the DAO, you have a distributed consensus platform for all shareholders to participate in. Decisions are made democratically through a proposal system ("Should we invest x amount of Ether into y?"), and regulated semi-autonomously by Ethereum contracts. I say semi-autonomously because there is a sort of "board of directors" that takes proposals and filters them out to make sure that a) there aren't too many proposals to be voting on, and b) all the proposals to be voted on are reasonable. You can also split off your stake in the DAO into a smaller DAO if you feel your voice isn't being heard or you don't like the direction the current DAO is going. This is what was attacked the first time IIRC.
There's a whole lot more to it of course, but that's basically how I understand it.
Let's say the members of the DAO voted to make an investment. How does the subject of the investment receive the funds and what mechanism ensures that the DAO actually receives any returns to which it may be entitled to based on the terms of the investment?
> A flexible decentralized autonomous organization leveraging the wisdom of the crowds to benefit the DAO Token Holders [...] The DAO is a for-profit DAO that will diligently use the ETH under its control to create value and provide benefits to its members while collaborating and improving the decentralised ecosystem as a whole.
That's snarky and unnecessary. And your linked site actually doesn't define the term until the third page in, after using "DAO" many times. And even then it's not a definition, it's a sentence that happens to spell it out. I had to ctrl-F to find it.
Agreed the original article does a great job. However, without the "sensational" title and simpler explanation people were not paying proper attention to this.
The original article discussed a bunch of other things as well -- everyone should read it to understand the details.
By people you mean traders. This sensationalism is utterly unnecessary since the non-traders involved with Ethereum read the original article and are capable of understanding it.
"Who are these people[1] and what credentials do they have to build and run a cryptocurrency platform?"
[1] https://angel.co/ethereum-1
Today, not a single cryptographer, mathematician, or anyone with software security experience is listed on the Ethereum Foundation member list[2]. I am not attacking any individuals by themselves, but as a group this says a lot.
For the record, what I see listed online today is a: consultant, magazine founder, a programmer, and a lawyer. On the advisory board a sales person, a psychologist, a leveraged debt consultant. On the "special advisors" list, which I have no idea what this means, maybe someone who answered a phone call a few times, one person with a bunch of business credentials, something "fintech" related with little explanation, and a tech CEO.
Maybe the Ethereum Foundation doesn't need anyone with deep experience in cryptography and security?
you are looking at a page listing boards and advisors, of course those wouldn't be the technical people.
Look at the core teams behind the different tools (too many to list here quickly), as well as the devs working in companies in the ecosystem such as consensys and ethcore, they are all quite qualified and smart people. Two examples come to mind are vlad zamfir and Dr. Christian Reitwiessner.
I'm not really familiar with either of them so maybe there's ton of security experience that they have that I'm not aware of... but I sure wasn't able to find any when I looked up the history of either of those two people. If you wanted to make the case that they had programming experience, sure, totally. But software security experts? How do you figure either of them being one of those?
Your comment from a year ago was pretty much entirely wrong: The ethereum platform has so far been stable and without exploits to this date. The exploits of theDAO and the exploits described in the article are smart program exploits, not exploits in the underlying platform.
Could the solidity programming language have some more features to protect inexperience smart contract programmers from themselves? Certainly, nobody is disputing that.
This is unfair to banish a company for not having enough "security experience". It could happen to anyone (i mean making such a design mistake), plus they afaik had some external audits.
How is it unfair ? We're speaking about crypto-currency here. "crypto" is so damn hard than even experts make mistakes indesign or implementation, and very often in both. And when they don't, it still doesn't mean it's secure... And now it's ok to have no expert and to use the result to manage _currency_ ?!?
It might sound weird, but yeah, I'd like to have knowledgeable people to deal with my money
Please don't be uncivil. It's damaging to collegial conversation, and it's against the rules (https://news.ycombinator.com/newsguidelines.html). Please edit such stuff out of your comments here.
Generally speaking the longer someone has been in a specific field, the lower the probability of them thinking of a new method or agreeing with new things. This is a general pattern across the board with anything ews, startups, projects, etc.
As somebody working with a lot os startups, having somebody with 30 years of a specific core competency on the founding team is a huge red flag.
You're making the mistake of believing that the CV's of token board or foundation members have anything at all to do with quality, reliability or integrity.
Such beliefs lead to the Appeal to Authority fallacy, and others.
You may want to read that list again. Over half of Tor's board of directors have deep experience in software security. And even their attorney has given talks at hacker conferences and is very, very well respected. Tor's board shows precisely the opposite: a deep list of well qualified people to run an organization that works on an important piece of security software.
I did read it, which is why I said " a few people with the right background". I counted less than half, but my point was that it's okay for people without technical background to sit on the board of well known crypto projects.
I'm messing around with contracts to do about a dozen different things, and it turns out to be easy to meet this restriction, as long as I'm willing to design the UI accordingly. (E.g. don't send money to lots of users in one step, just update their balances and make them call a withdraw function.)