Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Ethereum Smart Contracts

gjermundbjaanes.com

Post reply on HN
Print view View original

71–80 of 162 posts

Re: Understanding Ethereum Smart Contracts

#71

Post by Slartie »

retube wrote: post #52
decentralised wrote: post #13

Earlier quoted context omitted.

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?

You could argue that ICO-style crowdfunding is the only one of these problems that's currently not solvable in any other way, purely because it's impossible to get other people to invest obscene amounts of money into dubious projects if you don't have the ability to easily give them "tokens" of some kind in return that they can hope for to increase in value, regardless of whether the tokens are useful for their advertised purpose or not.

This "problem" (which is kind of an euphemism, you could just call it "scamming") is not solvable without having a blockchain as a neutral entity that secures the tokens in question. Just giving people the same essentially-worthless "fantasy tokens" stored in a conventional database that you promise to maintain will not cut it, as people won't give you hundreds of millions in this case, but will readily do so once your tokens are on a blockchain.

Re: Understanding Ethereum Smart Contracts

#72

Post by monocasa »

Slartie wrote: post #56
jackpeterfletch wrote: post #51

Earlier quoted context omitted.

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…

EVM is a 256-bit architecture, so it probably doesn't a BigDecimal equivalent for financial transactions.

Re: Understanding Ethereum Smart Contracts

#73

Post by Brotkrumen »

jackpeterfletch wrote: post #54
Brotkrumen wrote: post #50

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.

The only thing seckimjohn showed is that contracts, paper or "smart", are only as good as they're written. Since contracts such as _red gave, "we are friends, this is our company, we share the EBT equally", exist right now, it's a perfectly realistic use case for a smart contract. Hell, I'd even do that for a small project.

Smart contracts being fixed and errors being exploitable is a valid criticism but it's not the be-all-end-all argument for them to have no real world applications.

Re: Understanding Ethereum Smart Contracts

#74

Post by DennisP »

jatsign wrote: post #61
lprubin wrote: post #57

Earlier quoted context omitted.

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?

The 500 lines of code is, to be clear, just a guesstimate. It really is related to how those lines of code are compiled into Ethereum opcodes. Maybe you can get a thousand lines of code. My point is that it's pretty small, compared to what most developers are used to. The max gas limit is voted on by Ethereum miners. They recently raised it to 6.7 million (I believe it was 4.5 million not so long ago). The gas is wha…

Aside from the gas limit there's a hard 24KB limit on bytecode size, to deal with a denial-of-service vulnerability that cropped up last year. Possibly that will be improved in some future upgrade.

Re: Understanding Ethereum Smart Contracts

#75

Post by aquadrop »

SanFranManDan wrote: post #55
jackpeterfletch wrote: post #51

Earlier quoted context omitted.

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 "f…

You might need to work with fractions of "atomic values" to get the desired level of accuracy. So you have to store not logical cents, but 1/100th of cents or something like that. Much easier and straightforward just use decimal-like type.

Re: Understanding Ethereum Smart Contracts

#76

Post by and0 »

retube wrote: post #52
decentralised wrote: post #13

Earlier quoted context omitted.

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?

This is what I'm waiting for someone to explain. It's the same with blockchain, though. It's all a very neat concept, but it doesn't solve anything real-world except to power Bitcoin.

Smart contracts just sound like... normal contracts. Like the ones that have been around in some form or another for millennia. Most contracts are just "if X then Y" but using legal lingo instead of code.

Re: Understanding Ethereum Smart Contracts

#77

Post by hhmc »

ringaroundthetx wrote: post #65
SeckinJohn wrote: post #47

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…

regarding number 2, the child would not have a way of selling that Ethereum before 2035.

Can't they just sell access to their address?

Re: Understanding Ethereum Smart Contracts

#78

Post by DennisP »

edf13 wrote: post #64
_red wrote: post #44

Earlier quoted context omitted.

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…

This is the main problem I see with smart contracts (Even with oracles?)... How do the nodes running the code all get the same response from an external data source? Even if they use a service such as oraclize if the contract calls https://api/query?param1 and it returns lets say the weather: Node1 gets: 15.2c Node2 gets: 15.3c We've already failed on consensus haven't we?

The nodes don't all separately query the source. Instead, someone queries the source and sends a transaction to the network, with the data and the source's signature. The transaction gets incorporated into a block, updates the state, and now everybody has the same data.

Re: Understanding Ethereum Smart Contracts

#79

Post by logfromblammo »

ringaroundthetx wrote: post #65
SeckinJohn wrote: post #47

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…

regarding number 2, the child would not have a way of selling that Ethereum before 2035.

They sell the proof of identity or authentication information that is used to associate a person with an Ethereum account to someone else, out of band. Ethereum only knows the address to send to, and has no idea who or what is behind it at the time.

If the beneficiary dies before 2035, their heirs will collect, for instance. It is pretty simple to do a TVM calculation to determine the current value of a future benefit, and without all that legal-system stuff that is being bypassed through use of smart contracts, the intent of the trust creator can be more easily bypassed.

Re: Understanding Ethereum Smart Contracts

#80

Post by abuiles »

jatsign wrote: 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…

re: tooling

I've been using Truffle too. My biggest issue when getting started was the cognitive overload. If you want to try Truffle I wrote a couple of simple guides that helps you deploy your first Ethereum smart contract to a test net https://blog.abuiles.com/blog/2017/07/09/deploying-truffle-c...

Post reply on HN