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

111–120 of 162 posts

Re: Understanding Ethereum Smart Contracts

#111

Post by alexasmyths »

Brotkrumen wrote: post #73
jackpeterfletch wrote: post #54

Earlier quoted context omitted.

_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…

""smart", are only as good as they're written"

There are so many things that go into contracts that cannot be articulated in 'code' that this all hardly makes sense.

Employment contracts are long. Comp packages can be complex.

And we all live in countries with employment laws etc. that require these things anyhow.

I don't see any actual real-world cases for Eth contracts just yet.

Re: Understanding Ethereum Smart Contracts

#112

Post by bjaanes »

fortenforge wrote: post #86

> Bitcoin transactions are pretty simple in what they do. You can do one single thing. One type of transaction. Skipping some details, it all boils down to TO (who is receiving money), FROM (who is sending money) and AMOUNT (how much money). This let’s bitcoin be a store of value with the capability to transfer the value between participants in the network. Doesn't Bitcoin script allow you to do far more complex thin…

Yes, technically true. You can do some stuff there, but it is somewhat limited. I said I was simplifying some details, this is one of them. It only adds to the confusion. I don't think many people use it. At least not for any really complex use cases (I may be wrong, but that is the extent of my knowledge).

Looking at this I don't see how it can do too much interesting stuff: https://en.bitcoin.it/wiki/Script

Re: Understanding Ethereum Smart Contracts

#113

Post by bjaanes »

scandox wrote: 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.

I completely understand that. I answered more or less the same question on Reddit yesterday and I hope it can bring some value here too:

In the same way that Bitcoin allows people to send money to each other without having to trust the other person, you can do computation without having to trust a centralized party to do that computation. And it doesn't have to be "computing" in the way you might think about it; it can be tracking, storing and securing information (generally a hash of that information) with some logic around it (who can append, payments, vote on things, etc.).

I wrote a blog post about some potential use cases. Most of which are realized only with smart contracts. Some are pretty "out there," but in the end it up to the innovators of the world to decide what we can or cannot do with this.

http://www.gjermundbjaanes.com/the-blockchain-innovation-par...

Re: Understanding Ethereum Smart Contracts

#114

Post by coryl »

fokinsean wrote: post #90
coryl wrote: post #62

I've also just begun to play with smart contract programming. One problem I'm having is with event listening. It seems that MetaMask doesn't yet support subscriptions, nor does my localhost testRPC instance pass it in the web3 object. Some have suggested I need to run my own node just to listen for contract events. Has anyone figured out an easier solution?

Quick question, do you have to download the full ethereum chain before you can start messing with smart contracts? Or is there a "light" client you can use?

You can use a test node called testrpc (now called ganache-cli ???) and connect to that.

Re: Understanding Ethereum Smart Contracts

#115

Post by Tobba_ »

Kranar wrote: post #103
Slartie wrote: post #95

Earlier quoted context omitted.

Self-quote: > any imaginable application in the "classic" financial sector Kranar: > working in the financial sector (high frequency trading) Okay, you got me there - you have pointed me to that single application from the financial sector where it is not totally acceptable to "waste" a few thousands of processor cycles to compute some money-related stuff. Granted, in HFT applications, these cycles may allow you to g…

>I work in the retail industry (think cash registers, retail sale accounting, that kind of stuff) and pretty much any legislation on this planet would obliterate us if we'd tell them that the result of the computations of our systems may be some cents up or down from the real result - the one someone would get who just scribbled the numbers on a sheet of paper and added them up manually. It is especially in cases lik…

How on earth is using the wonkiest possible representation a better solution when you need precise results? In this case, even integer overflow would be a better failure mode than being a few cents off - because it would get noticed pretty quickly in comparison.

Hell, floating point isn't even a good way of doing imprecise arithmetic on larger numbers. What you would actually want is log arithmetic, but that's not what the hardware implements (even though it's simpler). It gives you roughly the same overall precision over each range but stops it from suddenly being cut in half as the exponent changes.

Re: Understanding Ethereum Smart Contracts

#116

Post by maehwasu »

jatsign wrote: post #84
maehwasu wrote: post #66

Earlier quoted context omitted.

> You can break up your code into multiple contracts, but the tradeoff is an increased attack area. This is the way to get programs over 500 lines, and it doesn't increase the attack area as much as you'd think, since you can essentially hard-code the addresses of outside contracts into your code--it's not a combinatorial explosion.

That makes sense, thanks. I hadn't thought of making it hard-coded (or just set at construction). The examples I'd seen were "upgradable" tokens.

Yeah, I did a lot of upgradeable stuff early, but have since moved to more hardcoded stuff for that exact reason.

Re: Understanding Ethereum Smart Contracts

#117

Post by coryl »

jatsign wrote: post #63
coryl wrote: post #62

I've also just begun to play with smart contract programming. One problem I'm having is with event listening. It seems that MetaMask doesn't yet support subscriptions, nor does my localhost testRPC instance pass it in the web3 object. Some have suggested I need to run my own node just to listen for contract events. Has anyone figured out an easier solution?

I've had success listening to events using web3, against both testrpc and geth (on private and test networks). What version of web3 & testrpc are you using?

I'm using web3 1.0.0-beta.26, ganache-cli 6.0.3

I instantiate the web3 object as such: web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545"));

When I try to setup an event listener, console logs this:

Error: The current provider doesn't support subscriptions: HttpProvider

Re: Understanding Ethereum Smart Contracts

#118

Post by bkcreate »

Slartie wrote: post #39
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…

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

I think a good system to look at copying in the real world is the Czech Koruna or Japanese Yen. It is a real world example of a currency that doesn't use decimal values. This simplifies the math involved and by having each unit have a very small value you can replace cents, and you don't have money "dissapear" due to being rounded off.

Re: Understanding Ethereum Smart Contracts

#119

Post by hamiltonkibbe »

Kranar wrote: post #103
Slartie wrote: post #95

Earlier quoted context omitted.

Self-quote: > any imaginable application in the "classic" financial sector Kranar: > working in the financial sector (high frequency trading) Okay, you got me there - you have pointed me to that single application from the financial sector where it is not totally acceptable to "waste" a few thousands of processor cycles to compute some money-related stuff. Granted, in HFT applications, these cycles may allow you to g…

>I work in the retail industry (think cash registers, retail sale accounting, that kind of stuff) and pretty much any legislation on this planet would obliterate us if we'd tell them that the result of the computations of our systems may be some cents up or down from the real result - the one someone would get who just scribbled the numbers on a sheet of paper and added them up manually. It is especially in cases lik…

I think its generally assumed that the unqualified term "floating point" is generally referring to binary floating point, which is not the same as decimal floating point. You don't want to use binary floating point for representing money. Furthermore fixed-point refers to a decimal value with a fixed number of bits for the integral and fractional parts, which is not the same as previously suggested system with an implicit decimal point (e.g. multiplying by 10^N for N places of decimal precision). real fixed-point math can be a better and more accurate system if you're working within a well defined range. Regardless of the system you're using, there are only 2^N unique values that can be represented in N bits, binary floating point distributes them unevenly across a huge range. If you are representing a smaller range with a fixed-point system, it will necessarily give you better precision.
Post reply on HN