❶ 浠ュお鍧婁腑Ghost鍗忚璇﹁В
浠ュお鍧婁腑鐨凣host鍗忚锛氳В鍐抽珮棰戠巼鍑哄潡甯︽潵鐨勬寫鎴
鍦ㄤ互澶鍧婄殑涓栫晫閲岋紝姣忎釜鍖哄潡鐨勮癁鐢熸爣蹇楃潃涓涓鏂版椂浠ｇ殑寮鍚銆傜劧鑰岋紝骞冲潎15绉掔殑鍑哄潡鏃堕棿鐩歌緝浜庢瘮鐗瑰竵鐨10鍒嗛挓锛岃櫧鐒舵彁鍗囦簡绯荤粺鐨勫弽搴旈熷害鍜屽悶鍚愰噺锛屽嵈涔熷甫鏉ヤ簡鏂扮殑鎸戞垬鈥斺旈戠箒鐨勫垎鍙夈傝繖鏄涓鍦哄叧浜庢晥鐜囦笌绋冲畾鎬х殑鍗氬紙锛屽備綍鍦ㄥ揩閫熷嚭鍧楃殑鐜澧冧腑淇濇寔绯荤粺鐨勭З搴忎笌瀹夊叏鎬э紵绛旀堝氨闅愯棌鍦℅host鍗忚涔嬩腑銆
鍒嗗弶鐨勬牴婧愬湪浜庡揩閫熷嚭鍧楀甫鏉ョ殑鎸栫熆闅惧害闄嶄綆銆傛兂璞′竴涓嬶紝鐭垮伐Zarten1鍜孼arten2鍑犱箮鍚屾椂鍙戠幇鏂板尯鍧楋紝浣嗕俊鎭鍦ㄧ綉缁滀腑鐨勪紶鎾閫熷害鍙鑳芥參浜15绉掋傝繖灏卞舰鎴愪簡澶氫釜鍒嗗弶鐐癸紝姣忎釜鍒嗗弶鐐归兘鏈夊彲鑳芥垚涓烘柊鐨勪富閾俱傚ぇ鍨嬬熆姹犵殑绠楀姏浼樺娍浣垮緱浠栦滑鏇村规槗鑾峰緱鏂板尯鍧楋紝浣嗚繖鍚屾椂涔熷姞澶т簡灏忕熆宸ョ殑鍥版壈鍜岀郴缁熺殑瀹夊叏椋庨櫓銆
Ghost鍗忚鐨勭櫥鍦
涓轰簡鎵撶牬杩欎竴鍍靛眬锛屼互澶鍧婂紩鍏ヤ簡Ghost锛圙reedy Heaviest Observed Subtree锛夊崗璁銆傝繖涓鍒涙柊鐨勮В鍐虫柟妗堟簮浜嶻onatan Sompolinsky鍜孉viv Zohar鍦2013骞寸殑鏅烘収銆侴host鐨勬牳蹇冪悊蹇垫槸寮曞肩熆宸ヤ滑鍦ㄤ富閾句笂寤剁画鎸栫熆锛岃岄潪鍦ㄥ垎鍙夌偣缁х画绔炰簤锛屼粠鑰屽噺灏戜笉蹇呰佺殑鍒嗗弶銆
Ghost鍗忚鐨勫伐浣滃師鐞嗗備笅锛氬綋鍖哄潡A涔嬪悗鍑虹幇澶氫釜鍒嗗弶锛屽傚尯鍧梈arten鏈鍏堝彂甯冿紝瀹冨氨鏈夊彲鑳芥垚涓轰富閾俱傚傛灉鍚庣画鐨勫尯鍧梈arten_a鑾峰緱鐭挎潈锛屽畠浼氶夋嫨鎺ョ撼Zarten1銆乑arten2銆乑arten3绛夊彅鐖跺潡锛岀粰浜堜竴瀹氱殑濂栧姳锛岄紦鍔变粬浠鏀惧純鍦ㄨ嚜宸辩殑鍒嗘敮涓婄户缁鎸栫熆锛岃浆鑰屽姞鍏ヤ富閾俱傝繖鏍风殑鏈哄埗纭淇濅簡澶ч儴鍒嗙畻鍔涢泦涓鍦ㄤ富閾句笂锛岄檷浣庝簡榛戝㈡敾鍑荤殑鎴愭湰锛屽悓鏃舵縺鍙戜簡鐭垮伐鐨勭Н鏋佹с
鍦ㄥ栧姳鏈哄埗涓锛屽彅鐖跺潡鏄鍏抽敭銆傛瘡涓鍖哄潡鏈澶氭帴绾充袱涓鍙旂埗鍧楋紝涓斿栧姳閫掑噺锛岃窛绂昏秺杩滅殑鍙旂埗鍧楄幏寰楃殑濂栧姳瓒婂皯锛屼互姝ら紦鍔辩熆宸ュ敖鏃╁悎骞讹紝鍑忓皯鍒嗗弶銆備緥濡傦紝鎺ョ撼n涓鍙旂埗鍧楃殑鍖哄潡鍙浠ヨ幏寰楀嚭鍧楀栧姳鐨刵*1/32銆傝繖鏍风殑璁捐℃棦淇濊瘉浜嗙郴缁熺殑绋冲畾锛屽張骞宠浜嗗埄鐩婂垎閰嶃
鐪熷疄妗堜緥瑙ｆ瀽
璁╂垜浠閫氳繃涓涓瀹炰緥鏉ョ悊瑙ｈ繖涓澶嶆潅鏈哄埗銆傛煡鐪嬪尯鍧9634573锛岄氳繃Blockchain Explorer锛屾垜浠鐪嬪埌鍖呭惈涓涓鍙旂埗鍧楃殑鍖哄潡锛屽叾濂栧姳涓2.171342981784463037 ETH锛屽彅鐖跺潡鏈韬濂栧姳涓1.5 ETH銆傞氳繃璁＄畻鍏寮忥紝鎴戜滑鍙浠ラ獙璇佸栧姳鐨勫噯纭鎬э細鍥哄畾鍑哄潡濂栧姳鍔犱笂鍖哄潡Gas璐圭敤鍜屽彅鐖跺潡濂栧姳鐨勬诲拰锛屼笌缃戠珯鏄剧ず鐨勫栧姳瀹屽叏鍚诲悎銆
Ghost鍗忚鐨勫疄鏂斤紝浣垮緱浠ュお鍧婂湪蹇閫熷嚭鍧楃殑鐜澧冧腑鎵惧埌浜嗗钩琛°傚畠涓嶄粎鏄瀵圭幇鏈夐棶棰樼殑瑙ｅ喅锛屼篃鏄浠ュお鍧婁笉鏂浼樺寲杩浠ｇ殑浣撶幇锛岄勭ず鐫鏈鏉ユ洿楂樻晥銆佹洿瀹夊叏鐨勭綉缁滅幆澧冦傞氳繃鐞嗚В杩欎竴鍗忚锛屾垜浠鏇磋兘娆ｈ祻鍒颁互澶鍧婅儗鍚庣殑鎶鏈榄呭姏鍜屽伐绋嬪笀浠鐨勬櫤鎱с
❷ 网吧挖坑是什么意思
网吧挖坑是误写，这里应该是“网吧挖矿”，指的是在网吧用高性能电脑挖虚拟货币赚钱。
一、网吧挖矿实例：
“网吧上座率还是不高，上班日不足50%，电脑闲置的时候就挖矿。”王曦在江苏南通市拥有两家网吧，合近200台电脑，自从去年9月开始挖矿到现在，王曦已入账20多万元。
王曦口中的挖矿，指的是利用配备高性能显卡的电脑，根据特定的算法程序获取一定数量的虚拟货币，目前主要挖的是全球第二大数字货币以太坊。
“挖矿绝对是在有限的资源范围内能做的最好选择。”5月13日，网吧老板张力（化名）对时代周报记者直言，未来自己应该会一直采取正常经营网吧和挖矿结合的方式。
在张力和王曦看来，网吧挖矿是因为现有挖矿资源足够，所以风险相对较小，但并不意味着挖矿零风险。无论是挖矿设备，还是已经翻倍的显卡，对新手来讲都存在难以回本的风险。
二、网吧“挖矿”成趋势
随着移动互联网时代来临，网吧行业早已不似PC时代那般风光，尤其在疫情冲击下更是如此。
“因为去年疫情影响，网吧停业很长时间，人流量不是特别多，直到最近才稍微有点起色。据我了解，整个南通市区的大部分网吧都选择了挖矿。”王曦坦言，网吧挖矿已经在短时间内成为一种趋势。
❸ 浠涔堟槸ERC-20锛
鎻绉樺姞瀵嗕笘鐣屼腑鐨勫熀鐭筹細ERC-20鍗忚
鎯宠薄涓涓嬶紝鍖哄潡閾句笘鐣屼腑鏈変竴濂楅氱敤鐨勨滆瑷鈥濆拰鈥滆捐℃ā鏉库濓紝璁╁紑鍙戣呬滑鑳借交鏉惧垱寤轰笌浠ュお鍧婄綉缁滄棤缂濆规帴鐨勪唬甯併傝繖灏辨槸ERC-20锛屼竴涓璧嬩簣浠ュお鍧婄敓鎬佺郴缁熷己澶х敓鍛藉姏鐨勬爣鍑嗗寲鍗忚銆傚畠鏄浠ュお鍧婁负鍖哄潡閾句笘鐣岃础鐚鐨勫熀鐭筹紝涔熸槸棣栦釜鐪熸ｆ剰涔変笂棰犺嗘х殑搴旂敤锛岃╂垜浠涓鎺㈢┒绔熴
ERC-20锛屽叏绉颁负Ethereum Request for Comment 20锛屾槸寮鍙戣呬滑鍒涢犲彲浜掓崲浠ｅ竵鐨勮摑鍥俱備互澶鍧婏紝浣滀负棣栦釜鍘讳腑蹇冨寲鐨勮櫄鎷熻揣甯佸钩鍙帮紝璧嬩簣浜嗗紑鍙戣呬滑鏃犻渶涓蹇冨寲鏈烘瀯鍗冲彲鏋勫缓搴旂敤鐨勫彲鑳斤紝鑰孍RC-20鍗忚灏辨槸鍏朵腑鐨勫叧閿銆傚畠灏卞儚鏄寮鍙戣呬滑鎵嬩腑鐨勪竴鎶娾滅憺澹鍐涘垁鈥濓紝绠鍖栦簡浠ｅ竵鍙戣岀殑杩囩▼锛岄檷浣庝簡鎴愭湰锛屼娇寰椾唬甯佹垚涓哄尯鍧楅摼椤圭洰鐨勬牳蹇冪粍鎴愰儴鍒嗐
ERC-20鐨勪环鍊煎拰褰卞搷鍔涗笉瀹瑰皬瑙戯紝瀹冩槸浠ュお鍧婁紬澶氬崗璁涓鏈涓轰汉鐔熺煡鐨勩傚畠涓嶄粎鎺ㄥ姩浜嗛栨′唬甯佸彂琛岋紙ICO锛夌殑鍏磋捣锛屽敖绠ICO楗卞彈浜夎锛屼絾纭瀹炲姞閫熶簡鍖哄潡閾炬妧鏈鐨勬櫘鍙婂拰搴旂敤鍒涙柊銆侲RC-20鐨勬祦琛岀敋鑷冲偓鐢熶簡璇稿俆RC-20杩欐牱鐨勨滃儚绱犵骇鈥濇ā浠胯咃紝鏄剧ず鍑哄叾鍦ㄥ競鍦轰笂鐨勫法澶у奖鍝嶅姏銆
涓轰簡鏇寸洿瑙傚湴鐞嗚ВERC-20锛屾兂璞′竴涓嬩竴涓灏忓尯鐨勫晢鎴蜂滑锛屽悇鑷鍙戣岃嚜瀹跺簵閾虹殑娑堣垂鍌ㄥ煎崱銆備互澶鍧婂氨鍍忓皬鍖虹殑鐗╀笟鍏鍙革紝鎻愪緵浜嗙粺涓鐨勫偍鍊煎崱鍙戣屽拰鍏戞崲瑙勫垯锛岃繖灏辨槸ERC-20銆傚畠璁╁晢鎴蜂滑杞绘澗鍒涘缓涓撴湁浠ｅ竵锛屾秷璐硅呭垯鍙浠ユ柟渚垮湴鍦ㄧ敓鎬佺郴缁熶腑娴佸姩銆傝繖绉嶅悎浣滄ā寮忎績杩涗簡鐢ㄦ埛銆佸紑鍙戣呭拰鍖哄潡閾剧綉缁滅殑鍏辫耽灞闈銆
涓惧嚑涓鐭ュ悕鐨勫簲鐢ㄥ疄渚嬶紝Tether锛圲SDT锛夈丆hainlink锛圠INK锛夈丅inance coin锛圔NB锛夌瓑閮芥槸鍩轰簬ERC-20鍗忚鐨勪唬甯併俆ether鐨刄SDT锛屽挨鍏朵互鍏禘RC-20鐗堟湰鍦ㄥ畾鎶旴OX鐨勫疄璺典腑鐨勫箍娉涘簲鐢ㄨ屼负浜烘墍鐭ワ紝閫氳繃ExinOne鍙浠ュ疄鐜颁笌BOX鐨勮嚜鍔ㄥ寲瀹氭姇鎿嶄綔銆
BOX锛岃繖涓鍖哄潡閾炬暟瀛楄祫浜у紑婧愰厤鏂癸紝姝ｆ槸ERC-20鍗忚鐨勫彈鐩婅呫傚畠鐨勬牳蹇冪粍鎴愰儴鍒哫IN鍜孶NI锛屼互鍙夿OX鏈韬锛岄兘閲囩敤浜咵RC-20鏍囧噯銆傛病鏈塃RC-20锛孊OX鍙鑳芥棤娉曞疄鐜板叾鐜版湁鐨勫姛鑳藉拰鍒涙柊銆
鎬昏岃█涔嬶紝ERC-20鏄鍖哄潡閾句笘鐣屼腑鐨勫叧閿鍩虹璁炬柦锛屽畠鐨勫嚭鐜拌╀互澶鍧婄敓鎬佺郴缁熸洿鍔犵箒鑽ｏ紝涓哄紑鍙戣呭拰鐢ㄦ埛鎻愪緵浜嗘棤闄愬彲鑳姐傚畠鐨勫奖鍝嶅姏鍜屽疄鐢ㄦэ紝涓嶄粎浣撶幇鍦ㄦ帹鍔ㄤ簡鍘讳腑蹇冨寲閲戣瀺锛圖eFi锛夌殑鍙戝睍锛屼篃濉戦犱簡鍖哄潡閾惧簲鐢ㄧ殑鏈鏉ユ牸灞銆
❹ 如何找到区块链的密码,区块链的密钥是什么
【深度知识】区块链之加密原理图示(加密,签名)先放一张以太坊的架构图：
在学习的过程中主要是采用单个模块了学习了解的，包括P2P,密码学，网络，协议等。直接开始总结：
秘钥分配问题也就是秘钥的传输问题，如果对称秘钥，那么只能在线下进行秘钥的交换。如果在线上传输秘钥，那就有可能被拦截。所以采用非对称加密，两把钥匙，一把私钥自留，一把公钥公开。公钥可以在网上传输。不用线下交易。保证数据的安全性。
如上图，A节点发送数据到B节点，此时采用公钥加密。A节点从自己的公钥中获取到B节点的公钥对明文数据加密，得到密文发送给B节点。而B节点采用自己的私钥解密。
2、无法解决消息篡改。
如上图，A节点采用B的公钥进行加密，然后将密文传输给B节点。B节点拿A节点的公钥将密文解密。
1、由于A的公钥是公开的，一旦网上黑客拦截消息，密文形同虚设。说白了，这种加密方式，只要拦截消息，就都能解开。
2、同样存在无法确定消息来源的问题，和消息篡改的问题。
如上图，A节点在发送数据前，先用B的公钥加密，得到密文1，再用A的私钥对密文1加密得到密文2。而B节点得到密文后，先用A的公钥解密，得到密文1，之后用B的私钥解密得到明文。
1、当网络上拦截到数据密文2时，由于A的公钥是公开的，故可以用A的公钥对密文2解密，就得到了密文1。所以这样看起来是双重加密，其实最后一层的私钥签名是无效的。一般来讲，我们都希望签名是签在最原始的数据上。如果签名放在后面，由于公钥是公开的，签名就缺乏安全性。
2、存在性能问题，非对称加密本身效率就很低下，还进行了两次加密过程。
如上图，A节点先用A的私钥加密，之后用B的公钥加密。B节点收到消息后，先采用B的私钥解密，然后再利用A的公钥解密。
1、当密文数据2被黑客拦截后，由于密文2只能采用B的私钥解密，而B的私钥只有B节点有，其他人无法机密。故安全性最高。
2、当B节点解密得到密文1后，只能采用A的公钥来解密。而只有经过A的私钥加密的数据才能用A的公钥解密成功，A的私钥只有A节点有，所以可以确定数据是由A节点传输过来的。
经两次非对称加密，性能问题比较严重。
基于以上篡改数据的问题，我们引入了消息认证。经过消息认证后的加密流程如下：
当A节点发送消息前，先对明文数据做一次散列计算。得到一个摘要,之后将照耀与原始数据同时发送给B节点。当B节点接收到消息后，对消息解密。解析出其中的散列摘要和原始数据，然后再对原始数据进行一次同样的散列计算得到摘要1,比较摘要与摘要1。如果相同则未被篡改，如果不同则表示已经被篡改。
在传输过程中，密文2只要被篡改，最后导致的hash与hash1就会产生不同。
无法解决签名问题，也就是双方相互攻击。A对于自己发送的消息始终不承认。比如A对B发送了一条错误消息，导致B有损失。但A抵赖不是自己发送的。
在(三)的过程中，没有办法解决交互双方相互攻击。什么意思呢？有可能是因为A发送的消息，对A节点不利，后来A就抵赖这消息不是它发送的。
为了解决这个问题，故引入了签名。这里我们将(二)-4中的加密方式，与消息签名合并设计在一起。
在上图中，我们利用A节点的私钥对其发送的摘要信息进行签名，然后将签名+原文，再利用B的公钥进行加密。而B得到密文后，先用B的私钥解密，然后对摘要再用A的公钥解密，只有比较两次摘要的内容是否相同。这既避免了防篡改问题，有规避了双方攻击问题。因为A对信息进行了签名，故是无法抵赖的。
为了解决非对称加密数据时的性能问题，故往往采用混合加密。这里就需要引入对称加密，如下图:
在对数据加密时，我们采用了双方共享的对称秘钥来加密。而对称秘钥尽量不要在网络上传输，以免丢失。这里的共享对称秘钥是根据自己的私钥和对方的公钥计算出的，然后适用对称秘钥对数据加密。而对方接收到数据时，也计算出对称秘钥然后对密文解密。
以上这种对称秘钥是不安全的，因为A的私钥和B的公钥一般短期内固定，所以共享对称秘钥也是固定不变的。为了增强安全性，最好的方式是每次交互都生成一个临时的共享对称秘钥。那么如何才能在每次交互过程中生成一个随机的对称秘钥，且不需要传输呢？
那么如何生成随机的共享秘钥进行加密呢？
对于发送方A节点，在每次发送时，都生成一个临时非对称秘钥对，然后根据B节点的公钥和临时的非对称私钥可以计算出一个对称秘钥(KA算法-KeyAgreement)。然后利用该对称秘钥对数据进行加密，针对共享秘钥这里的流程如下：
对于B节点，当接收到传输过来的数据时，解析出其中A节点的随机公钥，之后利用A节点的随机公钥与B节点自身的私钥计算出对称秘钥(KA算法)。之后利用对称秘钥机密数据。
对于以上加密方式，其实仍然存在很多问题，比如如何避免重放攻击(在消息中加入Nonce)，再比如彩虹表(参考KDF机制解决)之类的问题。由于时间及能力有限，故暂时忽略。
那么究竟应该采用何种加密呢？
主要还是基于要传输的数据的安全等级来考量。不重要的数据其实做好认证和签名就可以，但是很重要的数据就需要采用安全等级比较高的加密方案了。
密码套件是一个网络协议的概念。其中主要包括身份认证、加密、消息认证(MAC)、秘钥交换的算法组成。
在整个网络的传输过程中，根据密码套件主要分如下几大类算法：
秘钥交换算法：比如ECDHE、RSA。主要用于客户端和服务端握手时如何进行身份验证。
消息认证算法：比如SHA1、SHA2、SHA3。主要用于消息摘要。
批量加密算法：比如AES,主要用于加密信息流。
伪随机数算法：例如TLS1.2的伪随机函数使用MAC算法的散列函数来创建一个主密钥——连接双方共享的一个48字节的私钥。主密钥在创建会话密钥（例如创建MAC）时作为一个熵来源。
在网络中，一次消息的传输一般需要在如下4个阶段分别进行加密，才能保证消息安全、可靠的传输。
握手/网络协商阶段：
在双方进行握手阶段，需要进行链接的协商。主要的加密算法包括RSA、DH、ECDH等
身份认证阶段：
身份认证阶段，需要确定发送的消息的来源来源。主要采用的加密方式包括RSA、DSA、ECDSA(ECC加密，DSA签名)等。
消息加密阶段：
消息加密指对发送的信息流进行加密。主要采用的加密方式包括DES、RC4、AES等。
消息身份认证阶段/防篡改阶段：
主要是保证消息在传输过程中确保没有被篡改过。主要的加密方式包括MD5、SHA1、SHA2、SHA3等。
ECC：EllipticCurvesCryptography，椭圆曲线密码编码学。是一种根据椭圆上点倍积生成公钥、私钥的算法。用于生成公私秘钥。
ECDSA：用于数字签名,是一种数字签名算法。一种有效的数字签名使接收者有理由相信消息是由已知的发送者创建的，从而发送者不能否认已经发送了消息(身份验证和不可否认)，并且消息在运输过程中没有改变。ECDSA签名算法是ECC与DSA的结合，整个签名过程与DSA类似，所不一样的是签名中采取的算法为ECC，最后签名出来的值也是分为r,s。主要用于身份认证阶段。
ECDH：也是基于ECC算法的霍夫曼树秘钥，通过ECDH，双方可以在不共享任何秘密的前提下协商出一个共享秘密，并且是这种共享秘钥是为当前的通信暂时性的随机生成的，通信一旦中断秘钥就消失。主要用于握手磋商阶段。
ECIES：是一种集成加密方案,也可称为一种混合加密方案，它提供了对所选择的明文和选择的密码文本攻击的语义安全性。ECIES可以使用不同类型的函数：秘钥协商函数(KA)，秘钥推导函数(KDF)，对称加密方案(ENC)，哈希函数(HASH),H-MAC函数(MAC)。
ECC是椭圆加密算法，主要讲述了按照公私钥怎么在椭圆上产生，并且不可逆。ECDSA则主要是采用ECC算法怎么来做签名，ECDH则是采用ECC算法怎么生成对称秘钥。以上三者都是对ECC加密算法的应用。而现实场景中，我们往往会采用混合加密(对称加密，非对称加密结合使用，签名技术等一起使用)。ECIES就是底层利用ECC算法提供的一套集成(混合)加密方案。其中包括了非对称加密，对称加密和签名的功能。
metacharset="utf-8"
这个先订条件是为了保证曲线不包含奇点。
所以，随着曲线参数a和b的不断变化，曲线也呈现出了不同的形状。比如:
所有的非对称加密的基本原理基本都是基于一个公式K=kG。其中K代表公钥，k代表私钥，G代表某一个选取的基点。非对称加密的算法就是要保证该公式不可进行逆运算(也就是说G/K是无法计算的)。*
ECC是如何计算出公私钥呢？这里我按照我自己的理解来描述。
我理解，ECC的核心思想就是：选择曲线上的一个基点G，之后随机在ECC曲线上取一个点k(作为私钥)，然后根据kG计算出我们的公钥K。并且保证公钥K也要在曲线上。*
那么kG怎么计算呢？如何计算kG才能保证最后的结果不可逆呢？这就是ECC算法要解决的。
首先，我们先随便选择一条ECC曲线，a=-3,b=7得到如下曲线：
在这个曲线上，我随机选取两个点，这两个点的乘法怎么算呢？我们可以简化下问题，乘法是都可以用加法表示的，比如22=2+2，35=5+5+5。那么我们只要能在曲线上计算出加法，理论上就能算乘法。所以，只要能在这个曲线上进行加法计算，理论上就可以来计算乘法，理论上也就可以计算k*G这种表达式的值。
曲线上两点的加法又怎么算呢？这里ECC为了保证不可逆性，在曲线上自定义了加法体系。
现实中，1+1=2，2+2=4，但在ECC算法里，我们理解的这种加法体系是不可能。故需要自定义一套适用于该曲线的加法体系。
ECC定义，在图形中随机找一条直线，与ECC曲线相交于三个点(也有可能是两个点)，这三点分别是P、Q、R。
那么P+Q+R=0。其中0不是坐标轴上的0点，而是ECC中的无穷远点。也就是说定义了无穷远点为0点。
同样，我们就能得出P+Q=-R。由于R与-R是关于X轴对称的，所以我们就能在曲线上找到其坐标。
P+R+Q=0,故P+R=-Q,如上图。
以上就描述了ECC曲线的世界里是如何进行加法运算的。
从上图可看出，直线与曲线只有两个交点，也就是说直线是曲线的切线。此时P,R重合了。
也就是P=R,根据上述ECC的加法体系，P+R+Q=0,就可以得出P+R+Q=2P+Q=2R+Q=0
于是乎得到2P=-Q(是不是与我们非对称算法的公式K=kG越来越近了)。
于是我们得出一个结论，可以算乘法，不过只有在切点的时候才能算乘法，而且只能算2的乘法。
假若2可以变成任意个数进行想乘，那么就能代表在ECC曲线里可以进行乘法运算，那么ECC算法就能满足非对称加密算法的要求了。
那么我们是不是可以随机任何一个数的乘法都可以算呢？答案是肯定的。也就是点倍积计算方式。
选一个随机数k,那么k*P等于多少呢？
我们知道在计算机的世界里，所有的都是二进制的，ECC既然能算2的乘法，那么我们可以将随机数k描述成二进制然后计算。假若k=151=10010111
由于2P=-Q所以这样就计算出了kP。这就是点倍积算法。所以在ECC的曲线体系下是可以来计算乘法，那么以为这非对称加密的方式是可行的。
至于为什么这样计算是不可逆的。这需要大量的推演，我也不了解。但是我觉得可以这样理解：
我们的手表上，一般都有时间刻度。现在如果把1990年01月01日0点0分0秒作为起始点，如果告诉你至起始点为止时间流逝了整1年，那么我们是可以计算出现在的时间的，也就是能在手表上将时分秒指针应该指向00：00：00。但是反过来，我说现在手表上的时分秒指针指向了00：00：00,你能告诉我至起始点算过了有几年了么？
ECDSA签名算法和其他DSA、RSA基本相似，都是采用私钥签名，公钥验证。只不过算法体系采用的是ECC的算法。交互的双方要采用同一套参数体系。签名原理如下：
在曲线上选取一个无穷远点为基点G=(x,y)。随机在曲线上取一点k作为私钥，K=k*G计算出公钥。
签名过程：
生成随机数R,计算出RG.
根据随机数R,消息M的HASH值H,以及私钥k,计算出签名S=(H+kx)/R.
将消息M,RG,S发送给接收方。
签名验证过程：
接收到消息M,RG,S
根据消息计算出HASH值H
根据发送方的公钥K,计算HG/S+xK/S,将计算的结果与RG比较。如果相等则验证成功。
公式推论：
HG/S+xK/S=HG/S+x(kG)/S=(H+xk)/GS=RG
在介绍原理前，说明一下ECC是满足结合律和交换律的，也就是说A+B+C=A+C+B=(A+C)+B。
这里举一个WIKI上的例子说明如何生成共享秘钥，也可以参考AliceAndBob的例子。
Alice与Bob要进行通信，双方前提都是基于同一参数体系的ECC生成的公钥和私钥。所以有ECC有共同的基点G。
生成秘钥阶段：
Alice采用公钥算法KA=ka*G，生成了公钥KA和私钥ka,并公开公钥KA。
Bob采用公钥算法KB=kb*G，生成了公钥KB和私钥kb,并公开公钥KB。
计算ECDH阶段：
Alice利用计算公式Q=ka*KB计算出一个秘钥Q。
Bob利用计算公式Q'=kb*KA计算出一个秘钥Q'。
共享秘钥验证：
Q=kaKB=ka*kb*G=ka*G*kb=KA*kb=kb*KA=Q'
故双方分别计算出的共享秘钥不需要进行公开就可采用Q进行加密。我们将Q称为共享秘钥。
在以太坊中，采用的ECIEC的加密套件中的其他内容：
1、其中HASH算法采用的是最安全的SHA3算法Keccak。
2、签名算法采用的是ECDSA
3、认证方式采用的是H-MAC
4、ECC的参数体系采用了secp256k1,其他参数体系参考这里
H-MAC全程叫做Hash-.其模型如下：
在以太坊的UDP通信时(RPC通信加密方式不同)，则采用了以上的实现方式，并扩展化了。
首先，以太坊的UDP通信的结构如下：
其中，sig是经过私钥加密的签名信息。mac是可以理解为整个消息的摘要，ptype是消息的事件类型，data则是经过RLP编码后的传输数据。
其UDP的整个的加密，认证，签名模型如下：
区块链密码算法是怎样的？
区块链作为新兴技术受到越来越广泛的关注，是一种传统技术在互联网时代下的新的应用，这其中包括分布式数据存储技术、共识机制和密码学等。随着各种区块链研究联盟的创建，相关研究得到了越来越多的资金和人员支持。区块链使用的Hash算法、零知识证明、环签名等密码算法:
Hash算法
哈希算法作为区块链基础技术，Hash函数的本质是将任意长度（有限）的一组数据映射到一组已定义长度的数据流中。若此函数同时满足：
（1）对任意输入的一组数据Hash值的计算都特别简单；
（2）想要找到2个不同的拥有相同Hash值的数据是计算困难的。
满足上述两条性质的Hash函数也被称为加密Hash函数，不引起矛盾的情况下，Hash函数通常指的是加密Hash函数。对于Hash函数，找到使得被称为一次碰撞。当前流行的Hash函数有MD5,SHA1,SHA2,SHA3。
比特币使用的是SHA256，大多区块链系统使用的都是SHA256算法。所以这里先介绍一下SHA256。
1、SHA256算法步骤
STEP1：附加填充比特。对报文进行填充使报文长度与448模512同余（长度=448mod512），填充的比特数范围是1到512，填充比特串的最高位为1，其余位为0。
STEP2：附加长度值。将用64-bit表示的初始报文（填充前）的位长度附加在步骤1的结果后（低位字节优先）。
STEP3：初始化缓存。使用一个256-bit的缓存来存放该散列函数的中间及最终结果。
STEP4：处理512-bit（16个字）报文分组序列。该算法使用了六种基本逻辑函数，由64步迭代运算组成。每步都以256-bit缓存值为输入，然后更新缓存内容。每步使用一个32-bit常数值Kt和一个32-bitWt。其中Wt是分组之后的报文，t=1,2,...,16。
STEP5：所有的512-bit分组处理完毕后，对于SHA256算法最后一个分组产生的输出便是256-bit的报文。
作为加密及签名体系的核心算法，哈希函数的安全性事关整个区块链体系的底层安全性。所以关注哈希函数的研究现状是很有必要的。
2、Hash函的研究现状
2004年我国密码学家王小云在国际密码讨论年会（CRYPTO）上展示了MD5算法的碰撞并给出了第一个实例（CollisionsforhashfunctionsMD4,MD5,HAVAL-128andRIPEMD，rumpsessionofCRYPTO2004，，EuroCrypt2005）。该攻击复杂度很低，在普通计算机上只需要几秒钟的时间。2005年王小云教授与其同事又提出了对SHA-1算法的碰撞算法，不过计算复杂度为2的63次方，在实际情况下难以实现。
2017年2月23日谷歌安全博客上发布了世界上第一例公开的SHA-1哈希碰撞实例，在经过两年的联合研究和花费了巨大的计算机时间之后，研究人员在他们的研究网站SHAttered上给出了两个内容不同，但是具有相同SHA-1消息摘要的PDF文件，这就意味着在理论研究长期以来警示SHA-1算法存在风险之后，SHA-1算法的实际攻击案例也浮出水面，同时也标志着SHA-1算法终于走向了生命的末期。
NIST于2007年正式宣布在全球范围内征集新的下一代密码Hash算法，举行SHA-3竞赛。新的Hash算法将被称为SHA-3，并且作为新的安全Hash标准，增强现有的FIPS180-2标准。算法提交已于2008年10月结束，NIST分别于2009年和2010年举行2轮会议，通过2轮的筛选选出进入最终轮的算法，最后将在2012年公布获胜算法。公开竞赛的整个进程仿照高级加密标准AES的征集过程。2012年10月2日，Keccak被选为NIST竞赛的胜利者，成为SHA-3。
Keccak算法是SHA-3的候选人在2008年10月提交。Keccak采用了创新的的“海绵引擎”散列消息文本。它设计简单，方便硬件实现。Keccak已可以抵御最小的复杂度为2n的攻击，其中N为散列的大小。它具有广泛的安全边际。目前为止，第三方密码分析已经显示出Keccak没有严重的弱点。
KangarooTwelve算法是最近提出的Keccak变种，其计算轮次已经减少到了12，但与原算法比起来，其功能没有调整。
零知识证明
在密码学中零知识证明（zero-knowledgeproof,ZKP）是一种一方用于向另一方证明自己知晓某个消息x，而不透露其他任何和x有关的内容的策略，其中前者称为证明者（Prover），后者称为验证者（Verifier）。设想一种场景，在一个系统中，所有用户都拥有各自全部文件的备份，并利用各自的私钥进行加密后在系统内公开。假设在某个时刻，用户Alice希望提供给用户Bob她的一部分文件，这时候出现的问题是Alice如何让Bob相信她确实发送了正确的文件。一个简单地处理办法是Alice将自己的私钥发给Bob，而这正是Alice不希望选择的策略，因为这样Bob可以轻易地获取到Alice的全部文件内容。零知识证明便是可以用于解决上述问题的一种方案。零知识证明主要基于复杂度理论，并且在密码学中有广泛的理论延伸。在复杂度理论中，我们主要讨论哪些语言可以进行零知识证明应用，而在密码学中，我们主要讨论如何构造各种类型的零知识证明方案，并使得其足够优秀和高效。
环签名群签名
1、群签名
在一个群签名方案中，一个群体中的任意一个成员可以以匿名的方式代表整个群体对消息进行签名。与其他数字签名一样，群签名是可以公开验证的，且可以只用单个群公钥来验证。群签名一般流程：
（1）初始化，群管理者建立群资源，生成对应的群公钥（GroupPublicKey）和群私钥（GroupPrivateKey）群公钥对整个系统中的所有用户公开，比如群成员、验证者等。
（2）成员加入，在用户加入群的时候，群管理者颁发群证书（GroupCertificate）给群成员。
（3）签名，群成员利用获得的群证书签署文件，生成群签名。
（4）验证，同时验证者利用群公钥仅可以验证所得群签名的正确性，但不能确定群中的正式签署者。
（5）公开，群管理者利用群私钥可以对群用户生成的群签名进行追踪，并暴露签署者身份。
2、环签名
2001年，Rivest,shamir和Tauman三位密码学家首次提出了环签名。是一种简化的群签名，只有环成员没有管理者，不需要环成员间的合作。环签名方案中签名者首先选定一个临时的签名者集合,集合中包括签名者。然后签名者利用自己的私钥和签名集合中其他人的公钥就可以独立的产生签名,而无需他人的帮助。签名者集合中的成员可能并不知道自己被包含在其中。
环签名方案由以下几部分构成：
（1）密钥生成。为环中每个成员产生一个密钥对(公钥PKi,私钥SKi)。
（2）签名。签名者用自己的私钥和任意n个环成员(包括自己)的公钥为消息m生成签名a。
（3）签名验证。验证者根据环签名和消息m,验证签名是否为环中成员所签,如果有效就接收,否则丢弃。
环签名满足的性质：
（1）无条件匿名性:攻击者无法确定签名是由环中哪个成员生成,即使在获得环成员私钥的情况下,概率也不超过1/n。
（2）正确性:签名必需能被所有其他人验证。
（3）不可伪造性:环中其他成员不能伪造真实签名者签名,外部攻击者即使在获得某个有效环签名的基础上,也不能为消息m伪造一个签名。
3、环签名和群签名的比较
（1）匿名性。都是一种个体代表群体签名的体制，验证者能验证签名为群体中某个成员所签，但并不能知道为哪个成员，以达到签名者匿名的作用。
（2）可追踪性。群签名中，群管理员的存在保证了签名的可追
❺ 区块链改变现有商业的10个案例吗
本文介绍了区块链目前的10个主要使用场景：
(1)跟踪全球供应链中的产品；
是区块链技术在安全溯源方面的典型使用场景，可以促进商品流通的信息跟踪、查询、验证和防伪，可以显著提高一些环节的效率。但是区块链的作用只能体现在链条上，却无法覆盖链条下的人操作的部分。
(2)保证3D打印质量并跟踪；
(3)创建个性化和终身的“一站式”病历；
区块链医疗保健可以跟踪任何人的完整病史，如药物、疾病、伤害以及与跨医疗系统、医生、药房和医疗计划的交易，并使患者能够控制自己的数据。区块链还可以转移保险支付：当诊所确认患者已经接受治疗，并防止欺诈或不准确的索赔时，智能合同可以自动触发保险条款。一些初创公司，如英国的Medicalchain、区块链公司Gem、麻省理工学院等企业和大学都在尝试这种使用。
(4)简化贸易物流；
传统贸易涉及复杂的进出口手续，整个链条上的所有参与者都需要大量的纸质单据进行交互，导致沟通成本很高。区块链可以优化这个系统。马士基和IBM创建了一个平台，将班轮、仓库、货运代理、港口、海关、出口商、进口商和贸易融资银行等服务整合到贸易生态系统中，并在区块链上运行的数据交换平台上相互操作。
(五)便利和保障海关贸易；
区块链已经在许多海关部门进行了测试，包括英国、韩国、新加坡、哥斯达黎加、墨西哥、秘鲁和东非15国集团。2017年，美国海关为区块链开发了14个用例，目前正在进行测试和评估。区块链对英国尤其有用：当英国离开欧盟关税同盟时，其报关单数量将从5500万增加到2.5亿以上(非欧盟贸易加上欧盟贸易，以前不需要海关文件)，这是目前英国软件程序无法完全处理的。区块链可以提供帮助：它可以追踪产品的来源，并帮助确定商品的原产地和适当的关税，例如注定要加入欧盟的一揽子关税。对于英国的28个边境机构，需要分析进口产品，如食品、安全和知识产权合规性，并安全透明地实时共享区块链项目。
(6)防止投票舞弊，保护选民身份；
区块链安全和身份保护功能可以减少欺诈，并鼓励选民相信他们的投票是匿名的，
提高投票率，让选举立竿见影。利用这项技术，选民可以用智能手机扫描他们的拇指，然后在选举日的通勤途中投票。如果每个人都通过区块链投票，没有人可以投两次票。投票记录不可侵犯，每个投票点都会即时记录每张选票的ID。
(7)为农民启动农作物保险；
根据特定农民需求定制的作物保险通常非常昂贵，而区块链技术可以通过确定触发条件并自动执行来降低成本。例如，农民可以为极端天气投保。如果极端天气影响了收成，区块链的保险合同会立即确认这一点，并支付农民的索赔。
建立能源生产者和使用者网络；
几十年前，一些公司引入智能电网，为能源生产者和需求者提供中介服务。现在，区块链可以优化智能电网，并为能源生产商和消费者提供一个区域性的中介能源交易平台。TenneT和位于布鲁克林的创业公司LO3能源都在尝试这项业务。
(9)打造可以独立运营的智慧城市；
区块链现在可以放大斗游物联网对城市运行的影响。例如，迪拜有一个在城市服务中实施区块链的试点项目。迪拜计划到2020年，在超过1亿份年度政府文件中使用区块链，包括所空镇销有签证申请、账单支付和执照更新。
(10)当货物到达外国买方时自动旅如向出口商付款；
区块链通过允许交易双方访问相同的数据和实时数字文件，改变了现有国际贸易中的信息不对称问题。不需要跨不同实体的不同数据库存储同一文档的多个副本。当连接到智能合约的传感器标记的货物到达时，将自动触发买方向卖方的汇款。
2.区块链工业当前面临的十大问题及其分析
2.1.区块链上的数据真的是真的不可篡改吗？
区块链的核心特性之一“防篡改”真的能实现吗？而“防篡改”真的有益无害吗？
报告指出区块链并非完全不可改变，并给出了区块链的三个弱点：
(2)可能被黑，51%的链被想篡改结果的人控制。
(3)“垃圾中的垃圾”问题存在了几个世纪。区块链的价值取决于链上的数据，输入到区块链的数据可能是不准确或欺诈性的。一种解决方案是使用传感器代替人工输入数据。
所谓“51%攻击”，就是利用计算能力的优势，取消已经发生的支付交易。如果有人掌握了50%以上的计算能力，他就能比别人更快地找到挖掘区块所需的随机数，所以他实际上拥有决定哪个区块的绝对有效的权利。从技术层面来说，51%的攻击是可以实现的，但是对于BTC等最早的加密货币来说成本非常高，他们已经建立了一个庞大的网络，这也是为什么BTC的网络10年来一直保持稳定的原因。但对于其他假币来说，风险更大。
另外，攻击者单纯发动51%攻击没有直接收益，必须与特定的做空和虚假充值挂钩。具体来说，它常常是为了某一笔交易的双重支出。攻击者停止攻击一次。持续的攻击成本很高，一旦成功就会停止攻击；第二，社区可以发布紧急布丁，并在区块链增加检查点。社区紧急同意攻击者的区块链无效。所以，51%的进攻有很多方法可以应对，对一个区块链来说也不会是世界末日。
2.2.谁拥有和维护区块链？又是谁问的外观？
题和损失负责？
既然区块链是一个分散的用户社区，谁来维护它呢？它不应该和网站一样需要人调节和维护吗？
对于许可链，例如联盟链和私有链，不需要代币等激励措施激励人们管理，有一个管理整个网络的经理。由于网络中的用户较少，协调成本相对较低。但是这样的网络容易受到安全方面的挑战，且随着网络用户数量的增加，协调成本将会增加。
对于联盟链和私有链，由于它们还是一个非常中心化的组织，验证的节点由这个组织自己认定，因此管理模式与传统的中心化机构没有很大区别。但是对于公有链，没有统筹整个网络系统的领导者，仅靠代币的激励来协调不同的利益群体，这无疑增加了整个生态的不稳定性。目前区块链行业发展处于非常早期，除了BTC的去中心化治理发展得较为成熟以外，ETH、EOS等公链治理中，创始人开发团队则占据着非常核心的作用，是公链“规则的制定者”，整个生态虽然实现了局部去中心化，但在战略发展方向上，创始人依然发挥举足轻重的地位。因此笔者认为，区块链的去中心化只能是一个不断趋近的终极目标，从项目诞生到成熟，其去中心化程度应该不断增强，如下图所示。项目开发初期，创始人及其开发团队对整个生态起绝对的引导作用，随着项目生态的成熟、参与人数不断增多，原始的开发团队则应逐渐淡化自己的引导作用。整个网络维护需由生态上所有的开发者、用户等共同决定。而对于最后网络出现的问题，则只能由所有参与者一起承担。
图 区块链项目的中心化程度与发展阶段关系示意图
2.3． 智能合约真的智能吗？
智能合约还没有那么智能的第二个原因是它们的条目可以被作恶者操纵，比如缔约方或者向区块链过去交易账本添加交易记录的矿工。一项研究表明，ETH智能合约中有3.4%容易受到黑客攻击。
智能合约确实能优化很多中间程序，但就目前的产业实践来看，还远远称不上智能。一份合格的智能合约，应该包括一切可能发生的情况。因为智能合约的核心要义就是“即使在最阴暗的环境中，也要做出最公正的裁决”。
以太坊与比特币之间的区别在于，以太坊是图灵完备的，通过该平台可以实现种类更多、条款更复杂的合约，当然这样做的代价是，复杂的合约内容使其变得更加难以分析。通常情况下，复杂度与发生漏洞的机率是成正比的；复杂度越高，发生漏洞的机率就越大。
对于以太坊提出的理念“代码即法律”，然而代码因自身的漏洞招致黑客攻击使其还不足以形成“法律”的权威，因此和传统需要政府信任背书，律师、法庭等中介机构协调相比，目前的合约还显得过于粗糙。
2.4． 区块链上有身份盗窃吗？
社交媒体账户中有3%都是虚假的，因此能够在区块链上创造假的账户吗？区块链上的身份会被窃取吗？
区块链可以为用户创建一个数据不可篡改的个人数据库，但是如何满足用户“篡改”的需求呢？这或许就是区块链技术发展的一个悖论，对于用户的需求，我们可能需要从上链的标准以及权限管理角度进行展开。
2.5． 区块链可以互相连接吗？
一个区块链以一种方式记录实体或用户的数据，而另一个区块链以另一种方式记录相同实体或用户的相同数据。一个支离破碎的系统中，多个账簿彼此不相连，就会形成一个“营运孤岛”的世界，或者称“数据孤岛”。用户需要同时注册多个系统才能因为不同的目的和不同的人进行交易。
针对不同链的价值传递需求，跨链技术是关键，能有效衔接不同的联盟链或者私有链，促进区块链向外拓展和连接。目前主流的跨链技术有公证人机制（Notary schemes）、侧链/中继（Sidechains/relays）、哈希锁定（Hash-locking）、分布式私钥控制（Distributed private key control）等。
2.6． 区块链如何与链下数据库相连？
如果一方的数据和文档在链下，而另一方的数据和文档在链上，那么双方能否进行交互呢？在公司的数据库中，公司一半在区块链上的数据可否与另一半的数据进行交互呢？
这些挑战是众所周知的，而且正在得到解决。例如，可以在链上和链下数据库中运行相同的查询和分析。风险是从区块链上导到链下的数据不再不可窜改，研究人员认识到数据安全以及汇集、转换和优化链上和链下数据集是重大挑战。
2.7． 区块链能给洗钱提供便利吗？
洗钱是一个巨大的全球性问题，金额高达1-2万亿美元，约占全球GDP总额的2% - 5%。银行和有关部门正在进行反击，每年花费大约80亿美元来打击腐败问题。全世界的银行都需要做KYC验证。
由于区块链的匿名特性、特别是匿名币的出现，BTC被很多人诟病成为洗钱的工具。然而BTC的匿名仅仅是链上的匿名，人与链的交互，BTC与法币的交互均会留下痕迹，并不是如很多媒体宣传的那么“无法无天”。BTC每笔交易都需要对应地址的转移，而地址的交易记录均可以查询。此外，BTC与法币进行兑换这一环节是链下进行，仍逃不过监管，如果交易中任意一方的现实身份暴露，那么这笔交易里的所有参与方都难以逃脱追索。
2.8． 区块链会消耗完世界上所有的能源吗
BTC有惊人的能源需求，运营比特币一年需要爱尔兰一年的能源消耗。因为BTC的POW共识机制需要矿工挖矿来进行交易验证。有人担忧随着网络的增加以及BTC价值的上涨，能源需求将会快速增长。其实矿工自身有动机阻止这种事情发生，区块链的可扩展性受到可用性、能源成本以及矿商自身财力的限制。目前的替代方案是POS共识机制，POS机制通过持币者的持币数量选择验证者。
其实可以看到除了早期以BTC为首的一批加密货币，目前绝大多数区块链项目已经考虑到了POW的弊端，在不断创新共识机制，避免对能源的过度消耗。因此区块链还不足以对能源造成如此巨大的消耗。
2.9． 区块链会抢走我们的工作吗
对于区块链，如果人们可以彼此直接交易，那么区块链对银行、律师等中介有什么影响呢？区块链不太可能成为就业杀手，它将像任何技术一样，通过改变公司的业务和收入模式来改变工作的本质。
人工智能大火时也会不断有人问这样的问题，我们一方面享受科技给我们带来的便利，另一方面，又担心科技将我们取代。区块链最大的挑战不是技术本身，而是改变传统的利益分配模式。区块链的技术能够去掉某些中介环节，打破中心化机构对很多资源的垄断，进而改变利益格局，这也是区块链最具革命性意义的一点。
2.10． 美国在区块链行业的发展处于落后吗？
从全球来看，美国的区块链行业还处于起步阶段，德勤（Deloitte）在2018年对金融服务、医疗保健、科技行业、电信、制造业和其他行业的1053名高管进行了调查，只有14%的美国受访者认为区块链运用在他们的生产当中，相比之下，中国有49%，墨西哥有48%，英国有40%，加拿大为36%。计划也很滞后：41%的美国公司计划在区块链投资100万美元或更多，中国有85%，加拿大有74%，英国有72%，墨西哥有65%。
根据硅谷洞察发布的《区块链中美发展白皮书》来看，就ICO数量而言，北美与亚洲不相上下，从融资额来看，北美以78.5亿遥遥领先。因此，作为北美主要国家的美国，完全没有落后，相反，很多方面还处于领先地位。
《Harnessing Blockchain for American Business and Prosperity》
http://forex.hexun.com/2018-06-17/193222543.html
https：//jiahao..com/s？id=1606478434369770769&wfr=spider&for=pc
天机阁简介：天机阁（LD Research）成立于2018年7月2日，是一家致力于探索科技未知，以人类发展为动力，以“BASE Research for Solving Real Problems”为宗旨的研究院。
本文源自巴比特
区块链技术在商业领域的使用有哪些?
近年来，由于虚拟数字货币炒作的火爆，作为其底层技术的区块链也开始受到广泛关注。区块链具有去中心化、去信任、集体维护、可靠存储的特征，目前己在虚拟货币领域广泛使用。
自比特币诞生以来，目前全球已陆续出现了 1600多种虚拟货币，围绕着虚拟货币的生成、存储、交易等形成了庞大的产业链生态。但整体而言，行业尚处于初创期，离真正的价值使用区域还有很大距离。区块链经济的核心在于商业逻辑和组织形态的重构，因此需要在多个行业获得使用落地的实例来表明其价值。本文将从区块链与行业需求相结合的角度，探讨区块链在各行业使用的商业模式。
首先，区块链的核心是解决了信用的问题：
信用是一切商业活动与金融的基础。美国自2011年起实行可信身份识别，而中国则通过实 名制实现可监管的信息传播。区块链的意义在于第一次从技术层面建立了去中心化的信任， 实现了完全分布式的信用体系。
其次，区块链解决了价值交换的问题：
传统网络可以实现信息的点到点传递，但无法实现价值的点到点传递。因为信息是允许复制的，而价值必须确权且具有唯—性，因此必须依赖一个中心化机构才能做到价值传递。区块链完美地解决了此问题，提供了一个实现价值点到点传递的方法，在价值传递过程中，由网络来实现记帐而不依赖某个中心化的机构。所以区块链有望成为构建新型金融的基础设施，成为未来价值互联网的基石。
区块链的使用
目前区块链的使用，主要有两种模式：
1）原生型的区块链使用：直接基于去中心化的区块链技术，实现价值传递和交易等使用，例如数字货币；
2）“区块链+”模式：将传统的场景和区块链底层协议相结合，以便提高效率，降低成本。 预计区块链在各行业的使用，将以第二种模式为主。
区块链具有五大核心属性，即：交易属性（价值属性)、存证属性、信任属性、智能属性、 溯源属性。如上核心属性与行业的需求相结合，解决行业痛点问题，成为了区块链在各行业 使用的商业模式。
区块链+银行
1、跨境支付
跨境支付是长期以来困扰银行业的痛点问题。传统跨境支付手段包括两大类：一是网上支付，包括电子账户支付和国际信用卡支付，适用于零售小金额；二是银行汇款模式，适用于大金额的交易；二者均存在到账周期长、费用高、交易透明度低等问题。尤其是近年来随着跨境电商的兴起，方便、快捷、安全、低成本的跨境支付更成为行业的迫切需求。
区块链的作用：
区块链去中介化、交易公开透明的特点，没有第三方支付机构加入，缩短了支付周期、降低 费用、增加了交易透明度。例如，2017年12月，招商银行联手永隆银行、永隆深圳分行，成功实现了三方之间使用区块链技术的跨境人民币汇款。其清算流程安全、高效、快速，大幅提升客户体验。
2、供应链金融
该领域的痛点在于融资周期长、费用高。以供应链核心企业系统为中心，第三方增信机构很难鉴定供应链上各种相关凭证的真伪，造成人工审核的时间长、融资费用高。
区块链的作用：
区块链将共识机制、存在性证明、不可篡改、可追溯等特性引入供应链金融，不需要第三方增信机构鉴定供应链上各种相关凭证的真实性，从而降低融资成本、缩短融资周期。例如，2017年4月，上市公司易见股份与IBM中国研究院联合发布了区块链供应链金融服务系统“易见区块”，该系统主推医药场景，目前己有30余家医药流通企业在“易见区块”注册成功，截至7月底交易数量己接近8000笔，投放总金额超过一亿元。
3、数字票据
数字票据行业的痛点在于长期存在“虚假票据”、“一票多卖”等问题，为银行业的票据融资业务带来了风险。
区块链的作用：
区块链的存在性证明、不可篡改的特性，有效解决了虚假数字票据的问题；同时，区块链解决了双花问题，可避免"一票多卖"。例如，深圳区块链金融服务有限公司发行票链产品，基于区块链提供票据的融资服务，解决中小微企业的票据融资需求。合作银行包括赣州银行、贵阳银行、苏州银行、石嘴山银行、廊坊银 行、乌海银行、吉林九台农商银行、尧都农商银行、深圳农村行业银行、潍坊银行、中原银行等。此外，浙商银行、京东金融、恒生电子、海航等也在验证区块链数字票据服务。
区块链+证券
1、资产证券化
资产证券化是以未来的收入作为保证，以获得现在的融资。该领域的痛点在于：参与主体多， 操作环节多，交易透明度低，信息不对称，底层资产真伪无法保证。
区块链的作用：
区块链为资产证券化引入了存在性证明、不可篡改、共识机制等属性，能够实时监控资产的真实情况，解决了交易链条各方机构对底层资产的信任问题。各类资产如股权、债券、票据、 收益凭证、仓单等均可被整合进区块链中，成为链上数字资产，提升资产流转效率，降低成本。例如，2017年5月，网络金融与佰仟租赁、华能信托等在内的合作方联合发行区块链技术支持的 资产证券化ABS项目，发行规模达4.24亿元。
区块链+保险
1、保险业务
保险行业存在着信息不对称，客户与保险机构之间缺乏信任等问题：用户难以选择适合自己的保险产品，而保险机构则面临骗保的风险。
区块链的作用：
区块链的去中心化、开放透明、可追溯的特点，为保险机构和用户间建立良好的沟通渠道；保险标的信息在区块链上统一管理，不可篡改，帮助保险机构规避骗保风险；同时，通过智能合约可提升工作效率，降低成本。例如，法国保险巨头安盛保险（AXA）正在使用以太坊公有区块链为航空旅客提供自动航班延迟赔偿。如果航班延迟超过2小时，“智能合约”保险产品将会向乘客进行自动理赔。
2、征信管理
该领域的痛点在于征信机构的数据采集渠道有限，数据缺乏共享，导致难以准确表征个人或机构的信用情况；此外，数据收集过程中也存在如何保障用户隐私的问题。
区块链的作用：
区块链具有去信任、共识、不可篡改的特征，在技术层面保证了可以在有效保护用户隐私的基础上实现有限度、可管控的信用数据共享和验证。例如，目前中国平安的区块链征信业务已上线运行，此外国内的创业公司如上海矩真、LinkEye、布比区块链等也在进行联合征信、安全存证等方面的探索。
作为一种基础性技术，区块链在众多具有分布式处理、点对点交易、快速建立信任关系等需求的行业领域具有极大的使用价值，其核心是解决了信用的问题,实现了价值的点到点传递。因此被认为是未来价值互联网的基石。
区块链商业模式的核心在于，利用区块链引入的创新属性，与传统行业使用相结合，实现商业逻辑的重构，以便创造新的使用场景，或提升效率，降低成本。
预计区块链的使用将先从对信用、效率、安全性要求很高的泛金融领域切入：金融行业更关注效率与安全，区块链与其痛点的匹配度较高，可以为其系统性解决金融服务各环节存在的信任问题、效率问题、违约风险等；区块链的“交易、存证、溯源”等属性，在金融行业更易产生价值。同时，金融行业市场空间巨大，微小的进步就能带来巨大收益。
区块链也将延伸到社会生活的各个领域：区块链解决了数字化资产的管理、交易、转移等问题，因此将在资产数字化的浪潮中发挥重要作用，如供应链管理、数据服务、资产管理、公共服务、物联网等使用正在各个领域逐步落地，“区块链+”正在成为现实。
❻ Eth2瀛樻惧悎绾﹀彂甯冿紒濡備綍璐ㄦ娂浣犵殑 ETH 鎴愪负楠岃瘉鑰呭憿锛
鍏嶈矗澹版槑锛氭湰鏂囨棬鍦ㄤ紶閫掓洿澶氬競鍦轰俊鎭锛屼笉鏋勬垚浠讳綍鎶曡祫寤鸿銆傛枃绔犱粎浠ｈ〃浣滆呰傜偣锛屼笉浠ｈ〃鐏鏄熻储缁忓畼鏂圭珛鍦恒
灏忕紪锛氳板緱鍏虫敞鍝
鏉ユ簮锛歶nitimes
鍘熸枃鏍囬橈細Eth2瀛樻惧悎绾﹀彂甯冿紒濡備綍璐ㄦ娂浣犵殑ETH鎴愪负楠岃瘉鑰呭憿锛
浣滆咃細RyanSeanAdams
璇戣咃細Jhonny
缂栬緫锛歁ickey
Eth2椹涓婅佹潵浜嗐
鏍规嵁浠ュお鍧婂熀閲戜細瀹樺崥娑堟伅(瑙佷笅鍥)锛屼粖鏃Eth2瑙勮寖v1.0鐗堟湰姝ｅ紡鍙戝竷锛屽寘鎷鍙戝竷闃舵0淇℃爣閾句富缃戠殑瀛樻惧悎绾(DepositContract)鍦板潃锛孍th2淇℃爣閾惧垱涓栧尯鍧楃殑璇炵敓鏃堕棿棰勮℃槸2020骞12鏈1鏃ャ
褰撳墠Eth2瀛樻惧悎绾﹀凡缁忛儴缃诧紝浠ュお鍧婂熀閲戜細鍏甯冪殑瀹樻柟瀛樻惧悎绾﹀湴鍧涓猴細鏍规嵁Eth2LaunchPad(launchpad.ethereum.org)鏄剧ず锛屾埅鑷虫挵鏂囨椂锛屽凡缁忔湁19,685ETH琚璐ㄦ娂杩涗簡璇ュ瓨娆惧悎绾︿腑锛佸綋瀛樻惧悎绾︿腑鐨凟TH璐ㄦ娂閲忚揪鍒524,288ETH(涔熷嵆鏈16,384鍚嶉獙璇佽呭弬涓庢姷鎶硷紝姣忓悕楠岃瘉鑰呮姷鎶32ETH)鏃讹紝鍒橢th2淇℃爣閾句富缃(Eth2闃舵0)灏嗕簬12鏈1鏃ユｅ紡鍚鍔锛屽惁鍒欎俊鏍囬摼鍒涗笘鍖哄潡璇炵敓鏃堕棿灏嗛『寤躲俒澶囨敞锛欵th2LaunchPad鏄疎th2楠岃瘉鑺傜偣蹇鎹峰惎鍔ㄥ钩鍙癩
闇瑕佹敞鎰忕殑鏄锛屽傛灉ETH鎸佹湁鑰呮兂瑕佹垚涓篍th2鐨勯獙璇佽妭鐐癸紝蹇呴』瑕佸叿鏈夊繀瑕佺殑纭浠惰佹眰鍜屾妧鏈涓撻暱锛屽苟閫氳繃瀹樻柟鐨凟th2LaunchPad鎸夌収鍒嗘ヨ存槑杩涜屾搷浣滐紝鍒囧嬁鐩存帴灏咵TH鍙戦佸埌璇ュ瓨娆惧悎绾﹀湴鍧锛岀洿鎺ュ皢ETH鍙戦佸埌璇ュ悎绾﹀湴鍧灏嗗艰嚧浜ゆ槗澶辫触锛岃屽苟涓嶆剰鍛崇潃鍦‥th2涓婂弬涓庤川鎶笺傚備綍鎴愪负Eth2缃戠粶楠岃瘉鑰呭憿锛熷湪璐ㄦ娂ETH涔嬪墠闇瑕佹敞鎰忎簺浠涔堝憿锛......鎴戜滑灏嗗湪鏈鏂囨兜鐩栦互涓嬪唴瀹癸細
Eth2楠岃瘉鑰呯‖浠惰佹眰锛涢夋嫨鍜屽畨瑁匛th2瀹㈡埛绔鈥樻惌寤篍th1鑺傜偣锛涗娇鐢‥th2LaunchPad瀹屾垚璐ㄦ娂銆
01
纭浠惰佹眰
鍩轰簬Eth2鍘讳腑蹇冨寲鐨勮捐＄洰鏍囷紝棰勮Eth2楠岃瘉鑰呭皢浣跨敤鍚勭嶄笉鍚岀殑鍩虹璁炬柦(鏈鍦伴儴缃诧紝浜戠绛夌瓑)銆????濡傛灉浣犳ゅ墠灏氭湭鍙備笌Eth2娴嬭瘯缃戠殑ETH璐ㄦ娂鎿嶄綔锛屽彲浠ヤ娇鐢∕edalla娴嬭瘯缃戣繘琛岃瘯楠岋紝浠ユゆ潵鍐冲畾鍝绉嶈剧疆鑳藉熺粰浜堜綘鏈浣崇殑鍙備笌鎬ц兘銆傚湪姝ｅ紡鎴愪负Eth2淇℃爣閾鹃獙璇佽呬箣鍓嶏紝璇风‘淇濆厛鍦ㄦ祴璇曠綉涓婅繘琛屼竴浜涙祴璇曪紒鍙閫氳繃姝ら摼鎺ュ弬涓庢垚涓篗edalla娴嬭瘯缃戠殑楠岃瘉鑰咃細
https://medalla.launchpad.ethereum.org/涓嬮潰鎴戜滑灏嗙粰浜堜竴浜涙垚涓篍th2楠岃瘉鑰呯殑纭浠惰佹眰锛屽府鍔╀綘鎻愬墠鍋氬ソ鍑嗗囷紒
鎺ㄨ崘鐨勭‖浠惰勬牸锛氭搷浣滅郴缁:64-bitLinux,MacOSX,Windows澶勭悊鍣:IntelCorei7-4770orAMDFX-8310(鎴栨洿浣)鍐呭瓨:8GBRAM瀛樺偍绌洪棿:100GB鍥烘佺‖鐩樺彲鐢ㄧ┖闂翠簰鑱旂綉杩炴帴:瀹藉甫缃戠粶杩炴帴(10Mbps)鐢垫簮:涓嶉棿鏂鐢垫簮渚涘簲(UPS)
鎴栬呴夋嫨浜戞彁渚涘晢锛屼互DigitalOcean浜戞彁渚涘晢涓轰緥锛
鐩稿簲鐨凞igitalOcean铏氭嫙鏈哄疄渚嬶細鍐呭瓨:8GBRAM瀛樺偍绌洪棿:160GB鍥烘佺‖鐩樺彲鐢ㄧ┖闂存ｅ父杩愯屾椂闂:99.99%鍙鐢ㄦ:8涓鏁版嵁涓蹇$/姣忓皬鏃:$0.060$/姣忔湀:$40鏈浣庣‖浠惰勬牸:鎿嶄綔绯荤粺:64-bitLinux,MacOSX,Windows澶勭悊鍣:IntelCorei5-760orAMDFX-8110(鎴栬呮洿浣)鍐呭瓨:4GBRAM瀛樺偍绌洪棿:20GB鍥烘佺‖鐩樺彲鐢ㄧ┖闂翠簰鑱旂綉杩炴帴:瀹藉甫缃戠粶杩炴帴n(10Mbps)鐢垫簮:涓嶉棿鏂鐢垫簮渚涘簲(UPS)
鐩稿簲鐨凞igitalOcean铏氭嫙鏈哄疄渚:
鍐呭瓨:4GBRAM瀛樺偍绌洪棿:80GB鍥烘佺‖鐩樺彲鐢ㄧ┖闂存ｅ父杩愯屾椂闂:99.99%鍙鐢ㄦ:8涓鏁版嵁涓蹇$/灏忔椂:$0.030$/鏈:$20
02
閫夋嫨骞跺畨瑁匛th2瀹㈡埛绔
Eth2鏈夌潃澶氫釜瀹㈡埛绔鍙浠ラ夋嫨锛岄獙璇佽呭湪杩愯岄獙璇佽呰妭鐐逛笘鍙浠ラ夋嫨涓嶅悓鐨勫㈡埛绔瀹炵幇銆傛埅鑷崇洰鍓嶏紝宸茬粡鏈4涓狤th2瀹㈡埛绔鍥㈤槦寮鍙戠殑Eth2瀹㈡埛绔鍙渚涢夋嫨锛岃繖浜汦th2瀹㈡埛绔鍒嗗竷寮忥細Teku銆丯imbus銆丩ighthouse鍜孭ry銆
Eth2瀹㈡埛绔
Pry鐢盤ryaticLabs鍥㈤槦寮鍙(Discord)锛
Pry鏄鍩轰簬Go鐨凟th2瀹㈡埛绔瀹炵幇锛屼笓娉ㄤ簬瀹㈡埛绔鐨勫彲鐢ㄦс佸畨鍏ㄦу拰鍙闈犳с侾ry瀹㈡埛绔浣跨敤Go璇瑷缂栧啓锛屾牴鎹瓽PL-3.0璁稿彲杩涜屽彂甯冦備娇鐢ㄨ存槑:https://docs.prylabs.network/docs/getting-started/Github:https://github.com/pryaticlabs/pry/
Lighthouse鐢盨igmaPrime鍥㈤槦寮鍙(Discord)锛
Lighthouse鏄鍩轰簬Rust鐨凟th2瀹㈡埛绔瀹炵幇锛岄潪甯告敞閲嶉熷害鍜屽畨鍏ㄦс侺ighthouse瀹㈡埛绔鑳屽悗鐨勫洟闃烻igmaPrime鏄涓瀹朵俊鎭瀹夊叏鍜岃蒋浠跺伐绋嬪叕鍙搞侺ighthouse鏍规嵁Apache2.0璁稿彲杩涜屽彂甯冦備娇鐢ㄨ存槑:https://lighthouse-book.sigmaprime.io/Github:https://github.com/sigp/lighthouse
Teku鐢盋onsenSys寮鍙(Discord)锛
PegaSysTeku鏄鍩轰簬Java鐨凟th2瀹㈡埛绔瀹炵幇锛屽叾璁捐″拰鎼寤烘棬鍦ㄦ弧瓒虫満鏋勯渶姹傚拰瀹夊叏瑕佹眰銆俆eku鑾峰緱浜咥pache2鐨勮稿彲锛屽苟鐢↗ava缂栧啓锛孞ava鏄涓绉嶆垚鐔熶笖骞挎硾浣跨敤鐨勮瑷銆備娇鐢ㄨ存槑:https://docs.teku.pegasys.tech/en/latest/HowTo/Get-Started/Build-From-Source/Github:https://github.com/PegaSysEng/teku
Nimbus鐢盨tatus寮鍙(Discord)锛
Nimbus鏄涓涓狤th2鐮旂┒椤圭洰鍜屼竴涓瀹㈡埛绔瀹炵幇锛屾棬鍦ㄥ湪宓屽叆寮忕郴缁熷拰涓浜虹Щ鍔ㄨ惧(鍖呮嫭鎼杞借祫婧愰檺鍒剁殑纭浠剁殑杈冩棭鐨勬櫤鑳芥墜鏈)涓婅壇濂借繍琛屻侼imbus(Apache2璁稿彲)浣跨敤Nim璇瑷缂栧啓锛孨im鏄涓绉嶅叿鏈夌被浼间簬Python璇娉曠殑璇瑷锛屽彲缂栬瘧涓篊璇瑷銆備娇鐢ㄨ存槑:https://nimbus.team/docs/Github:https://github.com/status-im/nim-beacon-chain
03
瀹夎匛th1鑺傜偣
杩愯孍th2楠岃瘉鑰呰妭鐐归櫎浜嗛渶瑕佸畨瑁呬竴涓狤th2瀹㈡埛绔涔嬪栵紝杩橀渶瑕佽繍琛屼竴涓狤th1鑺傜偣锛屾Eth1鑺傜偣鐢ㄤ簬鐩戣嗛獙璇佽呯殑32ETH鎶垫娂瀛樻俱傚湪鎼寤篍th1鑺傜偣鏃讹紝鍙浠ユ湁澶氱嶉夋嫨锛屼互涓嬫槸鏈甯哥敤鐨勫惎鍔‥th1鑺傜偣鐨勫伐鍏凤細
鑷鎵樼＄殑Eth1鑺傜偣瀹㈡埛绔锛
OpenEthereum锛https://www.parity.io/ethereum/Geth锛https://geth.ethereum.org/Besu锛https://besu.hyperledger.org/en/stable/Nethermind锛https://www.nethermind.io/
绗涓夋柟鎵樼＄殑Eth1鑺傜偣瀹㈡埛绔锛
Infura锛https://infura.io/
04
杩愯孍th2楠岃瘉鑰呰妭鐐
绗涓姝:鑾峰彇ETH
濡傛灉浣犱笉鐔熸倝浠ュお鍧婏紝閭ｄ箞涓涓閲嶈佹ラゅ氨鏄鍏堣幏鍙栨垚涓篍th2楠岃瘉鑺傜偣鎵闇鐨凟TH銆傛瘡涓狤th2楠岃瘉鑰呰妭鐐归兘闇瑕佽川鎶32ETH銆傝锋敞鎰忥紝濡傛灉浣犳渶缁堟垚鍔熷湴鎴愪负浜咵th2楠岃瘉鑰咃紝鍒欐剰鍛崇潃浣犲规ゅ弬涓庤″垝鍋氬嚭浜嗛暱鏈熸壙璇(鍥犱负鐭鏈熷唴杩欎簺璐ㄦ娂鐨凟TH鏃犳硶鍙栧嚭)銆傚傛灉浣犻渶瑕佽幏鍙栦竴浜汦TH锛屽彲閫氳繃鍔犲瘑璐у竵浜ゆ槗鎵杩涜岃幏鍙栵紝姣斿傦細
娉曞竵浜ゆ槗鎵(缇庡浗鍦板尯):Coinbase鎴栬匞emini娉曞竵浜ゆ槗鎵(闈炵編鍥藉湴鍖):Binance鎴栬匥raken浠ュお鍧婂幓涓蹇冨寲浜ゆ槗鎵:Uniswap绗浜屾:鍓嶅線Eth2Launchpad骞冲彴杩涜孍TH璐ㄦ娂
鍦ㄨ繃鍘荤殑鍑犱釜鏈堜腑锛屼互澶鍧婂熀閲戜細(EF)銆丆odefiActivate鍜孌eepWorkStudio涓鐩村湪寮鍙戜竴涓狤th2楠岃瘉鑰呰妭鐐瑰揩鎹峰惎鍔ㄧ晫闈锛屼互浣跨敤鎴锋洿瀹规槗鍙備笌ETH璐ㄦ娂骞舵垚涓篍th2楠岃瘉鑰呫傝繖椤瑰伐浣滅殑缁撴灉灏辨槸Eth2LaunchPad骞冲彴鐨勫彂甯冿紝璇ュ钩鍙版棬鍦ㄥ畨鍏ㄥ湴鎸囧肩敤鎴峰畬鎴愮敓鎴怑th2瀵嗛挜瀵瑰苟灏32ETH璐ㄦ娂杩汦th2瀹樻柟鐨勫瓨娆惧悎绾︿腑銆侲th2LaunchPad鏄涓哄湪瀹跺嵆鍙鍙備笌Eth2楠岃瘉鑺傜偣鐨勪汉鑰岃捐＄殑锛屼篃鍗虫墦绠楄繍琛岃嚜宸辩殑Eth2楠岃瘉鑰呰妭鐐圭殑涓氫綑鐖卞ソ鑰咃紝骞舵帴鍙楀湪鑷宸辩殑璁＄畻鏈虹粓绔灞忓箷涓婅繍琛屽懡浠ゃ
绗浜屾:灏借亴璋冩煡
鍦ㄦ垚涓篍th2楠岃瘉鑰呰妭鐐圭殑杩囩▼涓锛岃姳鐐规椂闂撮槄璇讳竴涓婨th2LaunchPad骞冲彴涓婄殑鍐呭规槸闈炲父閲嶈佺殑锛佽ュ钩鍙颁笂鐨勨淥verview鈥(姒傝堪)閮ㄥ垎鏃ㄥ湪浣夸綘鐭ユ檽鍦ㄨ川鎶糆TH鏃舵墍娑夊強鐨勯庨櫓鍜岀浉鍏充俊鎭銆傚寘鎷锛(1)Eth2浣跨敤PoS(鏉冪泭璇佹槑鏈哄埗)鏉ヤ繚鎶ゆ暣涓缃戠粶銆備负姝わ紝缃戠粶闇瑕佹椿璺冪殑鍙備笌鑰(涔熷嵆楠岃瘉鑰)鏉ユ彁璁銆侀獙璇佸拰淇濊瘉鍖哄潡鐨勬湁鏁堟с備綔涓轰氦鎹锛岃瘹瀹炵殑楠岃瘉鑰呭皢鑾峰緱璐㈠姟濂栧姳銆傞噸瑕佺殑鏄锛岄獙璇佽呴渶瑕佽川鎶糆TH浣滀负鎶垫娂鍝侊紝鎹㈠彞璇濊达紝闇瑕佽川鎶间竴浜涜祫閲戙傛垚涓洪獙璇佽呯殑鍞涓鏂规硶鏄鍦ㄥ綋鍓嶇殑浠ュお鍧婇摼(涔熷嵆Eth1閾)涓婂線瀛樻惧悎绾﹀彂閫佷竴绗斿崟鍚戠殑ETH浜ゆ槗銆(2)瑕佹垚涓篍th2楠岃瘉鑰咃紝浣犻渶瑕佸规瘡涓瑕佽繍琛岀殑楠岃瘉鑰呰妭鐐归兘璐ㄦ娂32ETH銆傛敞鎰忥紝姝ゆ姷鎶艰繃绋嬫槸鍗曞悜涓嶅彲閫嗙殑銆(3)鍙鏈夌Н鏋佸弬涓嶦th2鍏辫瘑鐨勯獙璇佽呮墠鑳借幏寰楀栧姳銆傜荤嚎鐨勯獙璇佽呬細鍙楀埌鎯╃綒銆傛煇鑺傜偣绂荤嚎鍙楀埌鐨勬儵缃氬姏搴︿笌璇ヨ妭鐐圭Н鏋佸弬涓庡叡璇嗘椂鍙浠ヨ幏寰楃殑濂栧姳鐩稿綋銆(4)杩涜屾伓鎰忚屼负鎴栬呬笌Eth2瑙勮寖鑳岄亾鑰岄┌鐨勯獙璇佽咃紝寰堝规槗鍙楀埌缃氭病鎯╃綒(getslashed)锛岃繖灏嗘嫑鑷村法棰濇儵缃氥(5)楠岃瘉鑰呭瘑閽ユ槸浠庡敮涓鐨勫姪璁拌瘝(绉嶅瓙)娲剧敓鐨勩備綘鐨勭嶅瓙鏄鍙栨炬椂鐨勫敮涓閫斿緞銆傚洜姝わ紝鏈閲嶈佺殑鏄纭淇濆叾瀹夊叏锛佽峰囦唤濂戒綘鐨勫姪璁拌瘝锛(6)Eth2LaunchPad灏嗗府鍔╃敤鎴峰垱寤烘瘡涓楠岃瘉鑰呰妭鐐圭殑绛惧悕瀵嗛挜瀵(涓嶅悓鐨勯獙璇佽呰妭鐐归兘鏈変笉鍚岀殑绛惧悕瀵嗛挜锛屽嵆渚挎煇涓鐢ㄦ埛鍚屾椂杩愯屼簡澶氫釜楠岃瘉鑰呰妭鐐癸紝浣嗗悓涓涓鐢ㄦ埛杩愯岀殑澶氫釜楠岃瘉鑰呰妭鐐瑰彲浠ヤ娇鐢ㄥ悓涓涓鍙栨惧瘑閽)锛岃繖浜涚惧悕瀵嗛挜灏嗕細淇濆瓨鍦╧eystore(瀵嗛挜搴撴枃浠)涓(娉ㄦ剰锛氭瘡涓楠岃瘉鑰呯殑绛惧悕瀵嗛挜浼氫繚瀛樺湪鍗曠嫭鐨刱eystore涓)锛屽綋浣犱娇鐢ㄩ獙璇佽呰蒋浠跺紑濮嬮獙璇佷箣鍓嶏紝浣犻渶瑕佸皢keystore瀵煎叆鍒伴獙璇佽呰蒋浠朵腑銆傞氳繃Eth2LaunchPad鍒涘缓楠岃瘉鑰呰妭鐐规椂锛屼綘杩樹細鏀跺埌涓涓瀛樻炬枃浠(depositfile锛屾枃浠跺悗缂涓.json)锛岄渶瑕佸皢璇ュ瓨娆炬枃浠朵笂浼犺嚦Eth2LaunchPad缃戠珯涓娿(瀵规ゆ垜浠灏嗗湪涓嬫枃杩涜岃В閲)(7)楠岃瘉鑰呬箣闂寸殑杞璐﹁嚦灏戝湪Eth2闃舵1涔嬪墠鏄鏃犳硶瀹炵幇鐨勩傞獙璇佽呭繀椤荤瓑鍒伴樁娈2(澶х害杩樿2骞存椂闂)鎵嶈兘灏嗚祫閲戞彁鍙栧埌鏌愪釜鐗瑰畾鐨勫垎鐗囬摼涓娿(8)鐢变簬鑷冲皯鍦ㄩ樁娈1鍒版潵涔嬪墠锛岄獙璇佽呮棤娉曡繘琛岃浆璐︼紝鍥犳ゅ湪姝や箣鍓嶏紝楠岃瘉鑰呮棤娉曡嚜鎰块鍑洪獙璇佽呰屽垪骞堕噸鏂板惎鍔ㄨ妭鐐广傝繖鎰忓懗鐫楠岃瘉鑰呭皢闇瑕佸湪寰堥暱鐨勪竴娈垫椂闂村唴鍙備笌Eth2鍏辫瘑涔嬩腑锛(9)褰撳墠鐢ㄦ埛鍙備笌杩涙潵鐨勬槸鍒濆嬪彂甯冪殑Eth2鏂板瀷缃戠粶涓锛屼笌浠讳綍鏂拌蒋浠朵竴鏍凤紝瀛樺湪娼滃湪鐨刡ugs銆傝櫧鐒朵笉澶鍙鑳斤紝浣嗘綔鍦ㄧ殑bugs鍙鑳戒細瀵艰嚧鑺傜偣鍙楀埌slashing(缃氭病)鎯╃綒銆(10)涓轰簡鎴愪负楠岃瘉鑰咃紝浣犲皢闇瑕佺敓鎴愭柊鐨凟th2瀵嗛挜瀵广備负姝わ紝鍚屾椂涔熶负浜嗗畨瑁呴獙璇佽呰蒋浠讹紝浣犻渶瑕佸湪鎶鏈涓婃湁鑳藉姏鍦ㄨ＄畻鏈虹粓绔涓婅繍琛屽懡浠よ屻
绗涓夋ワ細鐢熸垚瀵嗛挜瀵瑰拰鍔╄拌瘝
瀵逛簬姣忎釜楠岃瘉鑰呰妭鐐癸紝浣犻兘闇瑕佺敓鎴愰獙璇佽呭瘑閽ュ瑰拰涓涓鍔╄拌瘝锛岃ュ姪璁拌瘝鐢ㄤ簬涔嬪悗鐢熸垚浣犵殑鍙栨惧瘑閽ャ傞栧厛锛屼綘闇瑕佸湪Eth2LaunchPad涓婂～鍐欎綘鎯宠佽繍琛岀殑楠岃瘉鑰呰妭鐐规暟閲忥紝浠ュ強浣犳兂瑕佸湪鍝绉嶆搷浣滅郴缁熶笂杩愯岄獙璇佽呰妭鐐广傝佷笅鍥????
鎺ヤ笅鏉ワ紝Eth2LaunchPad骞冲彴灏嗕负浣犳彁渚涗袱涓閫夐」鐢ㄤ簬鐢熸垚浣犵殑瀛樻惧瘑閽(depositkeys)銆備綘鍙浠ラ氳繃涓嬫柟閾炬帴鎵惧埌閽堝逛綘鐨勬搷浣滅郴缁熺殑璇︾粏璇存槑锛https://github.com/ethereum/eth2.0-deposit-cli/blob/master/README.ithubrepoandthenrunthe./.绗涓涓閫夐」鏄浣跨敤浣犱粠Eth2Githubrepo(https://github.com/ethereum/eth2.0-deposit-cli/releases/)涓嬭浇鐨勪簩杩涘埗鍙鎵ц屾枃浠讹紝鐒跺悗鍦ㄤ綘鐨勭粓绔绐楀彛涓杩愯./deposit鍛戒护銆傝佷笅鍥????璇疯板緱楠岃瘉浠ヤ笅璇ョ綉鍧锛岀‘淇濅綘浣跨敤鐨勬槸姝ｇ‘鐨勭綉鍧鏉ヤ笅杞斤紒
绗浜屼釜閫夐」鏄浠嶱ython婧愪唬鐮佹惌寤篸eposit-CLI宸ュ叿銆備綘灏嗛渶瑕佹寜鐓ц存槑杩涜屾搷浣滐紝浠ョ‘淇濅綘宸插畨瑁呮墍鏈夊繀闇鐨勫紑鍙戝簱鍜宒eposit-CLI宸ュ叿銆傝佷笅鍥????
褰撲綘瀹夎呬簡deposit-CLI宸ュ叿骞跺湪浣犵殑缁堢绐楀彛杩愯屾ゅ伐鍏锋椂锛屼綘灏嗚鎻愮ず锛
鏄庣‘浣犳兂瑕佽繍琛岀殑楠岃瘉鑰呰妭鐐圭殑鏁伴噺锛涗綘鎯宠佺敤浜庣敓鎴愬姪璁拌瘝鐨勮瑷锛涙槑纭浣犳兂瑕佽繍琛岄獙璇佽呰妭鐐圭殑缃戠粶(涓荤綉)銆
璇风‘淇濅綘璁剧疆鐨勬槸--chainmainnet锛屽惁鍒欏瓨娆惧皢鏃犳晥銆傜幇鍦锛屼綘灏嗚瑕佹眰璁剧疆浣犵殑瀵嗙爜(password)锛屼竴鏃﹀瘑鐮佺‘瀹氾紝浣犵殑鍔╄拌瘝灏嗚鐢熸垚銆傝风‘淇濅綘灏嗗姪璁拌瘝鍐欎笅鏉ワ紝骞跺皢鍏剁荤嚎瀛樺偍鍦ㄥ畨鍏ㄧ殑鍦版柟锛佸傛灉浣犲凡缁忔垚鍔熷湴瀹屾垚浜嗚ユラわ紝閭ｄ綘搴旇ュ彲浠ョ湅鍒颁笅鏂硅繖涓灞忓箷????
濡傛灉浣犲筪eposit-cli鏈夌枒闂锛岃疯块棶鍏禛itHubrepository:https://github.com/ethereum/eth2.0-deposit-cli
绗鍥涙ワ細涓婁紶浣犵殑瀛樻炬枃浠
浣犻┈涓婂氨瑕佸畬鎴愪簡锛佷笅涓姝ユ槸涓婁紶浣犲湪涓婁竴姝ョ敓鎴愮殑.json瀛樻炬枃浠躲傝ユ枃浠朵綅浜/eth2.0-deposit-cli/validator_keys鐩褰曚腑锛屾枃浠惰鍛藉悕涓篸eposit-data-[timestamp].json銆
绗浜旀ワ細杩炴帴浣犵殑閽卞寘
鎺ヤ笅鏉ュ氨鏄杩炴帴浣犵殑Web3閽卞寘锛屽苟鐐瑰嚮缁х画銆傝风‘淇濅綘鍦ㄤ綘鐨勯挶鍖呰剧疆涓閫夋嫨浜嗕富缃戠幆澧冦傚姞涓嬪浘????
绗鍏姝ワ細纭璁や氦鏄撲俊鎭鍙戣捣鎶垫娂瀛樻
褰撲綘杩炴帴閽卞寘骞剁‘璁や綘鐨勯挶鍖呭湴鍧鍚庯紝浣犲皢杩涘叆涓涓鎬荤粨鎬х殑椤甸潰锛岃ラ〉闈㈠皢鏄剧ず浣犻渶瑕佸悜瀛樻惧悎绾︿腑鍙戦佺殑ETH鎬绘暟閲(鏍规嵁姝ゅ墠浣犻夋嫨杩愯岀殑楠岃瘉鑰呰妭鐐规暟閲忥紝姣忎釜楠岃瘉鑰32ETH)銆傜偣鍑诲悓鎰忚︽垝妫鏌(alertchecks)锛岀劧鍚庡崟鍑荤‘璁や互瀵艰埅鍒版渶鍚庝竴姝モ斺旇繘琛屽疄闄呭瓨娆俱傜偣鍑烩淚nitiatetheTransaction鈥(鍙戣捣浜ゆ槗)锛屽皢浣犵殑ETH璐ㄦ娂杩涘畼鏂圭殑Eth2瀛樻惧悎绾︿腑銆備綘灏嗛渶瑕侀氳繃浣犵殑閽卞寘纭璁ゆ瘡涓楠岃瘉鑰呯殑32ETH璐ㄦ娂娆俱傚綋杩欑瑪浜ゆ槗纭璁や箣鍚庯紝浣犲氨瀹屾垚浜咵th2璐ㄦ娂鎿嶄綔浜嗭紒????绁濊春锛侊紒
❼ 以太坊中的计量单位及相互转换
首先我们来看一下以太币单位之间的转换，以太币的最小单位为wei，1个eth相当于10的18次方wei。通常，大家也使用Gwei作为展示单位。比较常用的就是eth，Gwei和wei。
为了使用和验证web3的操作命令，我们先进入geth的console控制台，在这里对具体的单位或进制转换进行详细的实例演示。
此转换方法为web3.toDecimal(hexString)。直接在控制台输入一下命令进行使用此函数进行转换。
通过此函数将十六进制的0x16转换为十进制的22。
转换函数：web3.fromDecimal(number)。
控制台命令及结果如下：
把给定数字或十六进制字符串转为 BigNumber 类型的实例。
此处转换需要注意的是BigNumber只会保留小数点后20位，超过20位的部分将会被截取掉。
上面表格中列出了以太币之间的单位进制，同样可以使用web3进行相应的转换，基本函数为web3.fromWei和web3.toWei(number, unit)。
具体实例如下：
其他的相关转换大家可自行尝试，下面列出相应的转换种类：
通过上面的函数，在交易的过程中我们就可以随意的单位进行发送交易，而不必使用最小单位wei。
通过查询余额的方法，我们也可以看出区块链中存储这些数据的单位为wei。
代币中的单位
在编写ERC-20的代币合约时我们可以指定代币的单位，比如：
这里就指定了代币单位精确到小数点后几位。比如精确到小数点后3位，那么1个代币存储时就是1000个最小单位的值。