9 ms·

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 o

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 with "money", this can make things tricky. - You can break up your code into multiple contracts, but the tradeoff is an increased attack area. - Dumb code is more secure than smart code. - The tooling is very immature. You'll probably use truffle, which just released version 4. It makes some things easier, some harder. It's version of web3 (1.0) may differ from what you were expecting (0.2). - The Ethereum testnet (Ropsten) has a different gas limit than the main net (4.7 million vs 6.7 million).

flashmob 9y ago
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 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 https://etherconverter.online
- workmandan 9y ago
  Dang you got there 3 minutes before me!
  - Slartie 9y ago
    Don't worry, I'm sitting in the same boat ;-)
- jatsign 9y ago
  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.
workmandan 9y ago
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?
- jatsign 9y ago
  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.
  - workmandan 9y ago
    Ah that makes sense - if Bitcoin keeps going at its present rate could 8 units of precision simply not be enough? Would a hard-fork be the solution to this?
    - jatsign 9y ago
      If one bitcoin were worth $100 million, then one "satoshi" (the smallest unit in bitcoin) would be worth a buck. So, 8 units of precision is probably plenty.
- jerrre 9y ago
  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).
  - deleted 9y ago
    [deleted]
Slartie 9y ago
> 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.
- jackpeterfletch 9y ago
  True, but the extra code around those solutions cost gas, of which your looking at around 500 lines worth. How long is BigDecimal.class?
  - SanFranManDan 9y ago
    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.
    - aquadrop 9y ago
      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.
lprubin 9y ago
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?
- jatsign 9y ago
  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 what is used to store the contract (thus increasing the block chain size), or to execute code (thus increasing the work load on the miners), so it's up to them. More Eth = more $$, but they have to weigh that against the downsides. If the price of Eth keeps going up, they have less incentive to increase the gas limit, because they get more money for doing the same work.
  - DennisP 9y ago
    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.
maehwasu 9y ago
> 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.
- Slartie 9y ago
  > and it doesn't increase the attack area as much as you'd think You should call Gavin Wood and tell him that :D
- jatsign 9y ago
  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.
  - maehwasu 9y ago
    Yeah, I did a lot of upgradeable stuff early, but have since moved to more hardcoded stuff for that exact reason.
abuiles 9y ago
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-contracts-to-rinkeby/ https://blog.abuiles.com/blog/2017/07/09/deploying-truffle-c...
AdamSC1 9y ago
For passing strings between a contract you can return the string as Bytes32 and let the remote contract query a function to access that.
- baby 9y ago
  Wait you can’t call another contract’s function (from a contract) if it takes a string as argument?
thomasthomas 9y ago
just curious, what are you doing with ETH contracts? working on a product or just hobby?

flashmob 9y ago

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 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 https://etherconverter.online

workmandan 9y ago
Dang you got there 3 minutes before me!
- Slartie 9y ago
  Don't worry, I'm sitting in the same boat ;-)
jatsign 9y ago
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.

workmandan 9y ago

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?

jatsign 9y ago
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.
- workmandan 9y ago
  Ah that makes sense - if Bitcoin keeps going at its present rate could 8 units of precision simply not be enough? Would a hard-fork be the solution to this?
  - jatsign 9y ago
    If one bitcoin were worth $100 million, then one "satoshi" (the smallest unit in bitcoin) would be worth a buck. So, 8 units of precision is probably plenty.
jerrre 9y ago
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).
- deleted 9y ago
  [deleted]

Slartie 9y ago

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

jackpeterfletch 9y ago
True, but the extra code around those solutions cost gas, of which your looking at around 500 lines worth. How long is BigDecimal.class?
- SanFranManDan 9y ago
  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.
  - aquadrop 9y ago
    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.

lprubin 9y ago

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?

jatsign 9y ago
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 what is used to store the contract (thus increasing the block chain size), or to execute code (thus increasing the work load on the miners), so it's up to them. More Eth = more $$, but they have to weigh that against the downsides. If the price of Eth keeps going up, they have less incentive to increase the gas limit, because they get more money for doing the same work.
- DennisP 9y ago
  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.

maehwasu 9y ago

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

Slartie 9y ago
> and it doesn't increase the attack area as much as you'd think You should call Gavin Wood and tell him that :D
jatsign 9y ago
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.
- maehwasu 9y ago
  Yeah, I did a lot of upgradeable stuff early, but have since moved to more hardcoded stuff for that exact reason.

abuiles 9y ago

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-contracts-to-rinkeby/ https://blog.abuiles.com/blog/2017/07/09/deploying-truffle-c...

AdamSC1 9y ago

For passing strings between a contract you can return the string as Bytes32 and let the remote contract query a function to access that.

baby 9y ago
Wait you can’t call another contract’s function (from a contract) if it takes a string as argument?

thomasthomas 9y ago

just curious, what are you doing with ETH contracts? working on a product or just hobby?