1703875604
区块链项目开发指南 [:1703875251]
1703875605
区块链项目开发指南 1.3 DApp中的用户身份
1703875606
1703875607
DApp的主要优点之一是它一般能保证用户的匿名性，但是许多应用要求用户必须经过身份验证这个过程才能使用应用。因为DApp中没有中央机构，验证用户身份成了一个挑战。
1703875608
1703875609
在中心化应用中，人们要求用户提交特定的扫描文件、OTP验证等，再验证用户身份。该过程称为Know Your Customer（KYC）。但是由于DApp中没有人负责验证用户身份，所以DApp不得不自己验证用户身份。DApp显然不能理解和验证扫描文档，也不能发送短信，因此需要用户提供那些它们可以理解和验证的数字标识。主要问题是几乎没有DApp有数字身份，只有少数人知道如何得到数字身份。
1703875610
1703875611
数字身份有多种形式。目前最受推崇、最热门的形式就是数字证书。数字证书（也称为公钥证书或者标识证书）是一个用来证明公钥所有权的电子文档。基本上，一个用户拥有私钥（private key）、公钥（public key）和数字证书（digital certificate）。私钥是秘密的，用户不应当与其他人分享；公钥可以与其他人分享；数字证书包含公钥和谁拥有公钥的信息。显然，生产这种证书并不难，因此数字证书总是由用户可以信任的授权机关颁发。数字证书有一个加密部分是用证书颁发机构（certificate authority）的私钥加密的。为了验证证书的真实性，我们只需要使用证书颁发机构的公钥解码该部分，如果成功解码，那么证书就是合法的。
1703875612
1703875613
即使用户成功获得了数字身份并得到DApp验证，还是有一个关键问题，那就是有各种各样的数字证书颁发机构。为了验证一个数字证书，我们需要该证书颁发机构的公钥。掌握所有证书颁发机构的公钥、更新/添加新的证书颁发机构的公钥是很困难的。因此，数字身份验证程序通常在客户端里，这样可以方便更新。但仅把验证程序转移到客户端并不能彻底解决问题，因为有很多颁发数字证书的机构，跟踪所有机构并把它们加到客户端是很麻烦的。
1703875614
1703875615
1703875616
为什么用户不验证彼此的身份？
1703875617
1703875618
在现实生活中，用户做交易时，通常会自己验证对方的身份或者可以请一个机构来验证身份，这个想法也可以应用到DApp中。在进行交易之前，用户可以手动验证彼此的身份，这个想法适用于人们彼此进行交易的DApp。假设有一个DApp是去中心化的社交网络，显然可以通过这种方式验证身份信息。假设一个DApp是用来买卖商品的，在支付之前买卖双方可以验证彼此的身份，尽管这个想法看起来是可行的，但是在实践中很难实现，因为你可能并不想每次进行交易的时候都验证身份，也不是每个人都知道如何验证身份。例如，假设有一个DApp是打车软件，用户显然不想每次叫出租车之前都进行身份验证。但如果只是偶尔交易，也知道怎样验证身份，就可以按程序验证身份。
1703875619
1703875620
由于这些原因，我们目前剩下的可选择方案是，由提供客户端的公司派人手动验证用户身份。例如，创建一个比特币账户不需要身份证明，但是当提取比特币并兑换成货币时，交易所会要求提供身份证明。客户端可以忽略未经验证的用户，不让他们使用，也可以对已经身份验证的用户开放使用。这个解决办法也会产生一些小问题，即如果转换客户端，会发现交互的用户不一样了，因为不同的客户端有不同的验证用户集。因此，所有用户可能决定只使用一个特定客户端。但这不是一个很大的问题，因为如果客户端不能有效验证用户，用户就可以方便地转向另一个客户端，而且不丢失关键数据，因为关键数据的存储是去中心化的。
1703875621
1703875622
1703875623
在应用中验证用户身份的想法是，使用户在进行一些欺诈行为之后难以逃脱，防止有欺诈/犯罪背景的用户使用应用，以及为网络中的其他用户提供相信某个用户就是他自称的人的方法。用什么过程来验证用户身份并不重要，用户总有办法伪装成其他人；用数字身份或者用扫描文件进行验证并不重要，因为二者都可能被盗或者被重复使用。重要的是让用户难以伪装成其他人，并收集足够的数据追踪用户，证明该用户进行了一些欺诈行为。
1703875624
1703875625
1703875626
1703875627
1703875628
区块链项目开发指南 [:1703875252]
1703875629
区块链项目开发指南 1.4 DApp中的用户账户
1703875630
1703875631
许多应用需要用户账户功能。与账户相关的数据只能由账户所有者进行修改。DApp和中心化应用不一样，DApp没有以用户名和以密码为基础的账户功能，因为密码不能证明账户中的数据变化是由账户所有者发出的请求导致的。
1703875632
1703875633
有多种方法能实现DApp中的用户账户，最热门的方式是使用公钥-私钥对（public-private key pair）来代表一个账户。公钥的哈希（hash）是账户的唯一身份。为了改变账户中的数据，用户需要用私钥签名。我们假设用户会安全地存储私钥。如果用户丢失私钥，就永远不能访问账户了。
1703875634
1703875635
1703875636
1703875637
1703875638
区块链项目开发指南 [:1703875253]
1703875639
区块链项目开发指南 1.5 访问中心化应用
1703875640
1703875641
DApp不能依赖于中心化应用，原因是存在单点故障。但是在一些情况下，并无其他办法。例如，如果DApp想读取一场足球比赛的成绩，它从哪里得到数据呢？尽管DApp可以依赖另一个DApp，但是国际足联（FIFA）为什么要创建一个DApp呢？国际足联不会仅仅因为其他DApp想要数据，就创建一个提供成绩却没有回报的DApp。
1703875642
1703875643
所以在一些情况下，DApp需要从中心化应用中抓取数据。但主要问题是DApp如何知道从一个域名中抓取的数据有没有被中间人篡改，数据是否还是真实的响应？根据DApp架构的不同，解决办法也有所不同。例如在以太坊中，智能合约不能直接发出HTTP请求，为了访问中心化API，可以使用Oraclize服务作为中间人。Oraclize为从中心化服务智能合约中抓取的数据提供TLSNotary验证。
1703875644
1703875645
1703875646
1703875647
1703875648
区块链项目开发指南 [:1703875254]
1703875649
区块链项目开发指南 1.6 DApp中的内部货币
1703875650
1703875651
中心化应用的所有者需要有盈利才能长期维护应用的运行。DApp虽然没有所有者，但是和中心化应用一样，DApp节点需要硬件和网络资源才能维持运行。DApp节点需要一些有用的回报来维持运行，于是内部货币登场了。大多数DApp都有内置内部货币，或者可以说最成功的DApp都有内置内部货币。
1703875652
1703875653
共识协议决定节点收取多少内部货币。根据共识协议，只有为维护DApp安全和运行做出贡献的那些特定节点可以赚取货币，只进行数据读取的节点没有回报。例如在比特币中，只有矿工（miner）成功挖矿才能赚取比特币。