# ^$ a0 E" g* t7 d4 [) j+ G @
- functiontransfer(address_to,uint256_value)publicreturns(bool){
- 9 ]' E1 Q: c7 ] s' j: g. x2 v
- //avoidsendingtokenstothe0x0address
- ; J2 F: J* k! l
- require(_to!=address(0));
- 6 } O7 x/ X4 x! Y- U3 V1 A+ {* x3 z
- //makesurethesenderhasenoughtokens
- 0 d9 L' q$ N. w& n I
- require(_value
2 w' A# K* I% J9 E" ]) r- R
在转账的时候只需要指定对方的地址，以及转账金额，而不需要指定转出的地址，因为可以使用smg.sender作为转出地址。
转账的方法很简单，连数据库都不需要调用，直接更改balance[]键值对的值就好了，给msg.sender的balance扣掉转账金额，给_to的balance增加转账金额。balance[]键值对永久的保存在智能合约自己的存储空间里。0 Z" v2 R3 m* s& i y5 B# Y
Thecontract’slong-termstorage,akey/valuestore.Unlikestackandmemory,whichresetaftercomputationends,storagepersistsforthelongterm.# A& o$ _; ~2 `& N! p
8 L7 z/ `2 Y' B$ h) p: R
https://github.com/ethereum/wiki ... r#ethereum-accounts
, ~( J; @% i% ^* ?; u
另外还有其他一些函数：% {/ Y! b" j5 v& U& P S
approve():让A地址可以调用B地址一定额度
$ J, r8 }8 y- c% ~
allownance():查看A地址可以从B地址调用的额度3 c7 x; a% L& T8 x. ]
- `9 d3 p6 L& `# {* q
transferFrom():使用B地址转账，和transfer()不同的是，transferFrom()需要制定转出地址
使用approve()函数有一个需要注意的问题，当需要更改额度，重新调用函数的时候，会有安全问题。因为区块链的操作不是实时的，而是作为等待被打包的交易，会有延迟，在更改额度的交易还没被打包之前。A地址可以将它权限范围的所有额度都用完，当更改额度的交易被打包后，A地址又可以将新的额度全部用完。
" y" Z3 q3 [9 r: X& O" B
改进方案+ N& q0 q3 b( f1 S4 a0 j
ERC20作为2015年提出的方案，实际使用中发现有些问题，然后也有人提出解决办法，比如ERC223和ERC777。% O+ I' V4 y9 _" ]- }
6 m. Z8 f) e: n$ G* S7 a. Z
但是升级ERC20标准非常困难，因为已有的ERC20标准已被广泛采纳，所有周边的生态都是使用这个标准——钱包、交易所。升级需要新建一个符合新的规范的智能合约，所有的交易所都需要更新智能合约地址。5 n6 e9 q5 T( }" l, s% M2 I
( y0 N; i# U9 L1 _1 Q
ERC20有什么用？
2 S7 }: J! w2 X; A$ U2 X
它是个统一标准，便于第三方工具的开发，如果没有标准，mist,metamask这类钱包工具就很为难，它们需要为每一种币适配。但是如果都遵循同样的标准，执行同样的操作，那么钱包工具就可以明确的知道对每个用户的操作需要调用哪个智能合约函数。当大多数token都遵循ERC20标准，你不遵守，那么你的token就会无法被钱包识别。+ x5 t4 Y6 J6 S* G3 H3 {% t) _2 T1 @
