Live data from Hacker News

Understanding Ethereum Smart Contracts

gjermundbjaanes.com

31–40 of 162 posts

Re: Understanding Ethereum Smart Contracts

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

Out of interest, are there any examples of real "live" structures in place using those mechanisms?

Re: Understanding Ethereum Smart Contracts

#32

Any other "gentle introductions" out there? Something with a complete walk-through both from contract creator's perspective and from some random node on the network. This one failed to explain how contract calls are executed - is it by a single node, by multiple nodes, do nodes compete with each other for the execution, what's their incentive, etc.

I hav started a youtube channel to teach ethereum and solidity: https://m.youtube.com/channel/UCZM8XQjNOyG2ElPpEUtNasA

Contract call can be broken down into 2 categories: state changing vs read-only.

If its a state changing contract call, it will be executed by every node on the network. In this case its considered a transaction. This transaction has to be mined in a block and cost ether. The new state will be stored on the blockchain only after the transaction has been succesfully mined.

The other kind of method call is read-only. Its free, ,is executed only by a single node, and does not alter the blockchain state.

Re: Understanding Ethereum Smart Contracts

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

Some very good points. I recall that the mainnet once had a gas per block limit of 4.7 mil before it was increased. The increase is something that is voted on by the miners, and has been fluid over the years. (Btw, it is something very similar to a block size limit in BTC, although it limits the storage + CPU usage, rather than just storage like in BTC)

About the point on using floats, one should never use floats when working with money, this is because floats are not precise and result in rounding errors (eg. 0.1 + 0.2 results 0.30000000000000004, see for details http://0.30000000000000004.com ). One of the simplest approaches to solve it is to work with the smallest units, so if working with dollars then you can use cents and that means you can use integers which give more precision, which is how Solidity currently deals with it, by working with the smallest unit of Ether which is 'wei'. Some of the units listed here https://etherconverter.online

Re: Understanding Ethereum Smart Contracts

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

Interesting point on the lack of floating-point support. I've dealt with storing fiat in real world software and using floating point is a big no-no due to the fact it is only an approximation by its very design. We therefore always stored money as integer cents/pennies etc. How is this approached with digital "money" where there is no smallest divisible unit?

Re: Understanding Ethereum Smart Contracts

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

Some very good points. I recall that the mainnet once had a gas per block limit of 4.7 mil before it was increased. The increase is something that is voted on by the miners, and has been fluid over the years. (Btw, it is something very similar to a block size limit in BTC, although it limits the storage + CPU usage, rather than just storage like in BTC) About the point on using floats, one should never use floats whe…

Dang you got there 3 minutes before me!

Re: Understanding Ethereum Smart Contracts

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

Some very good points. I recall that the mainnet once had a gas per block limit of 4.7 mil before it was increased. The increase is something that is voted on by the miners, and has been fluid over the years. (Btw, it is something very similar to a block size limit in BTC, although it limits the storage + CPU usage, rather than just storage like in BTC) About the point on using floats, one should never use floats whe…

And it's exasperated by the fact that most Tokens use 18 decimal places of precision. So "1" would be 1000000000000000000. As a programmer, I just found it harder to reason about numbers like that.

I ran into problems testing my solidity contract with javascript, because javascript isn't great at big numbers. Or division.

Re: Understanding Ethereum Smart Contracts

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

Interesting point on the lack of floating-point support. I've dealt with storing fiat in real world software and using floating point is a big no-no due to the fact it is only an approximation by its very design. We therefore always stored money as integer cents/pennies etc. How is this approached with digital "money" where there is no smallest divisible unit?

Most of the time by using 18 decimals. One "Ether" is 10^18 "wei", the smallest unit of currency. Most cryptotokens built on ethereum also use that many units...but not all.

Bitcoin is, IIRC, 8 units of precision.

Re: Understanding Ethereum Smart Contracts

#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 application in the "classic" financial sector.

What you need is either an integer data type plus a fixed, implied number of digits that you want to handle (so for example 105 represents 1 dollar and 5 cents), or a fixed-point numeric type (like for example BigDecimal in Java; there's lots of equivalents in other languages, most of them have something like "decimal" in their names), which essentially just stores the integer value together with the number of digits and features mathematical operations of pairs of these with each other.

Re: Understanding Ethereum Smart Contracts

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

Interesting point on the lack of floating-point support. I've dealt with storing fiat in real world software and using floating point is a big no-no due to the fact it is only an approximation by its very design. We therefore always stored money as integer cents/pennies etc. How is this approached with digital "money" where there is no smallest divisible unit?

I'm not sure if there are infinitely divisible currencies? The cryptocurrencies I know (Ethereum, Bitcoin) _do_ have a smallest divisible unit (wei and satoshi respectively).
Post reply on HN