Live data from Hacker News

Understanding Ethereum Smart Contracts

gjermundbjaanes.com

51–60 of 162 posts

Re: Understanding Ethereum Smart Contracts

#51
post #39
post #29

I've been programing my own Ethereum smart contract (virtual currency) for awhile now. Here's some gotchas off the top of my head: - You have about 500 lines of code to work with. This of course varies, but smart contracts have to be really small to fit in the max gas limit (6.7 million wei). - You can't pass strings between contracts (coming soon). - There are no floating point numbers. Since you're probably working…

> There are no floating point numbers. Since you're probably working with "money", this can make things tricky. That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable appli…

True, but the extra code around those solutions cost gas, of which your looking at around 500 lines worth.

How long is BigDecimal.class?

Re: Understanding Ethereum Smart Contracts

#52
post #10

What I'd greatly appreciate is a walk through of a plausible real world use case. I find it hard to concentrate on the technology itself until I understand the application.

Crowdfunding (ICOs) is a use case. DNS (ENS) is a use case. Organisational Transparency (Aragon) is a use case. Prediction Markets(Augur) are a use case. Electricity Markets (Grid+) are a use case. International payment card with zero fees (TenX) is a use case. I can go on for a while longer, there are hundreds of use cases but the question is: what would be a use case for you?

yes but any of that stuff can be accomplished with conventional databases and software stacks. What specific problem with respect to implementing any of the above is blockchain solving that conventional stacks can't?

Re: Understanding Ethereum Smart Contracts

#53
post #44
post #19

Earlier quoted context omitted.

Those are both really interesting thanks. I assume in case 2 Solidity language has some built-in mechanisms for ensuring that the current datetime is agreed across the whole network?

As DennisP said, yes there are mechanisms to ensure date is agreed upon. Your question of "consensus" brings up other interesting points. I think an increasingly valuable service in a new smart-contract world will be to have an "Outcomes As A Service" arbiter. This would be a trusted 3rd party that publishes real-world outcomes in a method that can be accessed reliably via smart contracts. Who will win the football g…

Services like Oracleize already allow you to do something similar to this.

Re: Understanding Ethereum Smart Contracts

#54

Earlier quoted context omitted.

1- 50% of what? Revenue into the company or dividens/salary etc out of the company? if it's the latter, then, how do we make sure that you don't spend $500.000 for trash bins for the office? Do we have to make sure every decision goes through the network? (i.e. who is the authority to decide what is reasonable and what is blatant fraud if things go sour AND is it even possible to make sure that nothing possibly can g…

Parent gives you an answer that is scoped to "divide incoming by half and send the halves to given addresses" and you criticizing that the answer doesn't cover all scopes you can come up with? Him: "This baker makes bread rolls". you: "What about dark bread? What about non-bread items? What's his broker?"

_Red gave two examples of Ethereum applications.

SeckimJohn quite quickly showed why neither work. The are some niche digital uses, but not the ones people often tout.

Ethereum contracts basically break down at the point they need to interact with the real world.

Re: Understanding Ethereum Smart Contracts

#55
post #39

Earlier quoted context omitted.

> There are no floating point numbers. Since you're probably working with "money", this can make things tricky. That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable appli…

True, but the extra code around those solutions cost gas, of which your looking at around 500 lines worth. How long is BigDecimal.class?

Likely you don't need a generic implementation of Decimal.

What money do you want to represent, they all have a "atomic value".

For instance, when working with dollars store cents. When working with Eth, store wei. etc.

I can't think of a use case of money that needs decimals except maybe computing ownerships percentage. but that should never be stored, but rather computed.

Anything that needs to be converted is a "front end" view. all computations should use atomic store of value, thus no conversion is needed in contracts.

Re: Understanding Ethereum Smart Contracts

#56
post #39

Earlier quoted context omitted.

> There are no floating point numbers. Since you're probably working with "money", this can make things tricky. That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable appli…

True, but the extra code around those solutions cost gas, of which your looking at around 500 lines worth. How long is BigDecimal.class?

Providing a decimal type would of course not be the job of the developer of a smart contract - I would expect that the smart contract platform would anticipate the necessity of convenient decimal number handling and thus provide a suitable abstraction.

In the case of Ethereum, it could either be provided in the language or on the virtual machine level. I'm not that much into the EVM's inner workings to judge whether a machine-level implementation would be a good idea from an architectural viewpoint, but it would definitely deliver the best possible performance and lead to the smallest amount of contract code, thereby saving on gas to deploy the contract. As a second-best solution, the language could provide such an abstraction - it would at least be able to apply optimizations when compiling the code down to EVM opcodes, which an implementation purely on the contract level would not be able to do.

Re: Understanding Ethereum Smart Contracts

#57
post #29

I've been programing my own Ethereum smart contract (virtual currency) for awhile now. Here's some gotchas off the top of my head: - You have about 500 lines of code to work with. This of course varies, but smart contracts have to be really small to fit in the max gas limit (6.7 million wei). - You can't pass strings between contracts (coming soon). - There are no floating point numbers. Since you're probably working…

A question about the 500 lines of code and tooling limitations. Is this something that is inherently an issue of the underlying technology or do you predict that this is something that is likely to be improved upon over time? And if you think it'll be improved, are we years away from big improvements? Less?

Re: Understanding Ethereum Smart Contracts

#58
post #25

Earlier quoted context omitted.

I know that one of the major power companies in Germany works on chargers for electric cars based on Ethereum; send x ether to the smart contact and the charging station will let you charge your car accordingly.

What bit of that needs a smart contract? Seems perfectly do-able without one, and you still need the same levels of trust even when there's a smart contract in there.

The smart contract is the tool to make sure* that transferred Ether results in power being transferred. Of course we could just use a blockchain like Bitcoin and define "send x BTC to wallet y and I promise you will get your power" - but in that case, the blockchain can just guarantee the value transfer, not the subsequent actions being undertaken.

* since this involves interaction with the outside world, I don't know a way at this point that 100% guarantees that your get your power. Curious how they tackle this.

Re: Understanding Ethereum Smart Contracts

#59

Earlier quoted context omitted.

Parent gives you an answer that is scoped to "divide incoming by half and send the halves to given addresses" and you criticizing that the answer doesn't cover all scopes you can come up with? Him: "This baker makes bread rolls". you: "What about dark bread? What about non-bread items? What's his broker?"

_Red gave two examples of Ethereum applications. SeckimJohn quite quickly showed why neither work. The are some niche digital uses, but not the ones people often tout. Ethereum contracts basically break down at the point they need to interact with the real world.

Well I'm entirely new to this and pretty blockchain sceptical but I don't think SeckimJohn showed why neither work, did he?

As I understand it each concern requires some kind of function/method which addresses it within the smart contract, right? So the real problem is that once you publish the contract you better make sure you haven't forgotten something important...

Re: Understanding Ethereum Smart Contracts

#60
post #17
post #15

Earlier quoted context omitted.

They all sound great. So what I'd love to see is a well written blog post describing how Ethereum would be put to work to achieve one of those goals and to give me an understanding of its superiority within the domain. I'm not demanding it and I'm not being snarky at all. It's just that's the level I'm at - without that kind of entry point I struggle to assess it.

Some of the use cases can be fairly simple (thus easier to see the value). 1. Me and You start a company together. We would like to split things 50/50. We setup an address such that when values are paid to it, half goes to you, half goes to me. Effectively we've created an "LLC with an Operating Agreement", but we aren't relying on political legal system / country to enforce. Enforcement is automatic and done by the…

> Me and You start a company together. We would like to split things 50/50. We setup an address such that when values are paid to it, half goes to you, half goes to me.

What is the real world use case for that, though? That seems like a contract that makes sense as long as you and I trust each other, which rather negates the purpose of a contract.

Some immediate issues that strike me:

* There's nothing to stop either of us offering the services of the company outside of that contract;

* There's no way to ensure that one of us isn't freeloading;

* If my wallet gets stolen you'll be paying half the earnings of the company to the hacker until the contract is somehow voided;

* Which raises the question of how can this contract get voided? Do either of us get to void it whenever we feel like it? What if I've lost my key? Do we potentially just have to live with the money being paid into hacked / unusable accounts forever?

So all you've really saved is the bother of dividing a number by two and doing bank transfers, in return for which you've gained significant operational burdens.

Post reply on HN