Web3 的设计原则

Web3的设计原则

基于分布式应用的区块链用户体验框架

备注：本文比较长，可直接跳到“概览”部分(cheetsheet)或是"结论"部分。

区块链开发者们正极力推动去中心化的宏伟蓝图，但是目前正在开发的 Dapp 却类似于 Web2.0 的原始应用。

使用 Dapps 的大多数用户仍然 "生活" 在 Web2.0 的世界中，甚至从未听过去中心化的 Web3 将会带来什么。

即使这部分用户进入 Web3 世界，当他们看到这些新生的 app ，无论是从专业术语的理解，开发 Dapps 的目的，还是原动力， 依旧会很难辨别它们与传统的 web apps 之间的区别。

必须承认的一点是，如 Drizzle,MetaMask 这些比较优秀工具的问世正解决上述 Web3 中面临的问题,并坚信这些问题终将被解决。

这些设计原则期望提出一些解决这些问题的方法，并提供指导以帮助设计人员和开发人员，使具备光明前景的 Web3 能够早日走进日常生活。

web3 设计 vs 区块链设计 其他人已经针对区块链设计撰文，文中展示了与 dapps 有关的前端用户体验设计。

尽管 Consensys 的首席设计师 Sarah Mills 撰写的文章非常激动人心，并且毫无疑问她是区块链领域设计师的主要领导者,但我认为“区块链设计”这个词 更适合定义区块链结构本身的属性以及其中的交互过程：比如共识算法,供应链,区块奖励，图灵完备，gas 计算成本，链上链下的治理机制等等。

本文中，我会着眼于 "web3 设计"，主要表明面向去中心化应用的用户体验设计。 因为尽管在文章中使用 "区块链" 能提高阅读量，但会使其变成 "clickbait"(clickbait 是描述网络内容的贬义术语，以牺牲质量或准确性为代价来吸引点击)

Web3 设计原则的初衷 现如今用户可以通过以下几种方法与部署在区块链上的智能合约进行交互：比如直接通过命令行，数字钱包或 dapp 浏览器，或是通过智能合约开发人员所开发的更 丰富的前端

显而易见的是大部分的 dapps 都采用了后者：结合基于分布式应用程序的处理经验来提供一个更丰富的用户界面。

作为开发人员，我们忙于构建区块链的基础设施和项目的智能合约，造成的结果是目前几乎没有 dapps 拥有可用的前端，即便某些 dapps 具备可用的前端，它在内容安全方面并不会和传统的应用程序有所差别。

然而 dapps 与普通的 web 或 移动 app 应存在根本上的不同，并且能够具备区块链所特有的去中心化，透明，无信任，不可变更性以及不可审查性。 以上所属的区块链特性到 Dapps 前端的映射是这些设计原则编码成可用工具的具体途径。

这么做的目的是一旦正确地应用后，登录 Dapp 的用户可以立刻知晓她正与其进行交互，更重要的是，可以访问具备区块链强大属性的工具，并信任与该应用程序的 每个交互过程。

web3 设计原则的一些想法

web3设计原则的目标受众是普通用户，尽管其中的一些设计原则面向的是具备技术基础的用户。

并不是每个 Dapps 都需要遵循所有的设计原则

实例中展现的解决方案只是一些初步的想法

某些 web3 设计原则建议使用外部工具，服务或库，而不是让每个开发人员实现他们的解决方案（在 "下一步" 中会展示更多的相关内容）

大多数 web3 设计原则将受益于类似 Bootstrap 这样的开发者友好型库(在"下一步"中会展示更多的相关内容)

如果你对这非常感兴趣，请直接移步文章末尾的 “下一步” 部分，以示如何将各部分的工作串联在一起

设计方法

设计也是包含预测问题并提供解决方案的艺术，在这种情况下，我试图 "投射" 用户在与 Dapps 交互时遇到的问题(在我看来它更好，因为它是 "向前推进"的词源意义)

相关的问题有：

遵循 Dapps 的相关要求是安全的吗？

如果搞砸的话，用户的财产会不会不再安全？

之前已经听说过加密方法能保护用户隐私，那对于用户发送的数据，会进行什么处理？它会被存储在什么地方？用户是否可以被识别？

用户输入的数据对哪些人是可见的？代码运行的起始点在那里？

如果用户这么做了之后会发生什么？

针对这种情况，用户应该如何对其进行加密操作？

假设区块链是可信的，那么用户该如何辨别 app 中的某些数据是可信的？

哪些数据来自于区块链？

用户如何对真正存储在区块链中的数据进行验证？

等等......

web3 设计原则针对上述问题以及更多潜在问题为开发者提供了相关工具

web3 设计原则的快速索引

这篇文章非常长，可以通过 "概览" 对设计原则进行快速的查看，然后跳转到感兴趣的部分

///TTT:信任的透明度设计原则

1-(读取数据)数据来源的透明度 区分区块链数据和非区块链数据 区分合约地址 将所有的区块链数据链接到独立的区块链浏览器 区分来源于 oracles 的数据 ——具体实例

2-(写入数据)交易的透明度 交易的种类（价值转移，函数调用，合约生成） [Permanence]交易动作是不可逆转的 [Value]交易动作涉及金钱或价值 [Privacy]区分需要用户识别的交易行为 [Factory]在用户名中生成合约的交易动作 -所有交易类型的设计指南 提前区分并确认未来的状态 以人类可读的格式以及智能合约要求的方式显示正用于事务的数据（链接：代码的透明度） gas 的建议价格以及如何重写交易（链接：gas 价格和交易重写） 管理交易等待的时间（链接：等待时间管理） 区分不属于交易的行为，以此确保安全性

3——（推送数据）智能合约事件的透明度 确保最终用户可以访问所有事件，包括仅用于开发人员的事件 应用相关性：仅显示与当前用户相关的信息中断消息 允许用户订阅，取消订阅或是暂时不接收某些事件

4-(历史)用户交易历史的透明度和可访问性 提供指定地址的所有交易历史 区分存储交易历史的位置（本地或是服务器）（链接：代码的透明性） 提供导航，搜索，导出和删除历史记录缓存的工具

5——(代码&环境)代码的透明度 区分处于使用状态的区块链 区分读/写操作中使用的智能合约的地址 区分开源代码（及其地址） 区分处于运行状态代码的位置（本地或是远程服务器） 区分 web3 提供商和区块链节点（本地节点，Dapp 控制节点，Metamask,infura,等等） 区分 Dapp 是在主网上运行还是在测试网上运行 区分来源于 oracles 的数据或受 oracles 影响的数据 （备注：oracles,区块链可信数据源）（链接：数据来源的透明度） 允许执行 DIY 代码：允许高级用户查看正在运行的代码并通过命令行自动执行 区分智能合约所需的输入部分

///通用 Web3 用户体验原则

6-Time/Wait 管理 区分区块链特定的时间段并管理不同阶段用户的等待事务 (管理用户的等待时间)在用户等待期间显示活性指标

7-人类可读哈希格式 显示哈希值的紧凑版本，始终显示哈希的初始和结束部分 总是在前面添加“0x”以表示它是一个哈希值 允许用户扩展完整地址/哈希 支持用户复制哈希值 尽可能使用缩写作为标题，缩写地址作为子标题 用户可以轻松地将自定义的人类可读名称，文本与地址和哈希相关联 将哈希的某种形式（即 Identicons,blockies 等）与地址绑定

8-永久的新手模式 与用户的交互过程中提供教育性的信息 提供第二级别或更高级别的教育内容：区块链基础知识和 Dapp 专业术语 最小化并逐步增加用户需要学习的新事物和概念的数量 尽可能提供“专家级别的解释”来加快学习 教育信息上下文要紧凑

9—— Gas 价格和交易逆转 区分 Gas 和 Gas 价格这两个术语（链接：新手模式） Gas 价格的建议范围以及时间近似值的上限和下限 显示转换成法定货币(FIAT)所需的 gas 价格 允许交易逆转

///DDP:去中心化设计原则

10——社区事务 社区中有多少其他成员 谁属于其他成员的范畴（选择适当的类别） 社区的构成（分组及其对项目的权力） 如果有的话，分享具备更大使命的项目以及用户对项目的贡献如何有助于项目的实现

11——未来的设计原则（第二部分） 身份和声誉 治理 交易所 ICO & 代币销售机制

TTT:信任透明度设计原则

Web3 的价值观： 如果用户不知道在哪里以及如何查看，那么它是不透明的 如果它是不透明的，就不能信任

所有的人都在谈论区块链的“无信任”和“透明度” 解释这两个假设只是部分正确的原因需要花费更长的时间，并且会偏离本篇文章的主题

在程序和软件上验证数据是可行的，但是与最终的用户体验相对抗时，这两个假设会分崩离析

除了许多加密项目或 Dapp 前端很少向用户显示它正在与之交互的智能合约地址或数据来源这一原因之外，目前对非技术用户来说理解独立的区块链浏览器，如 Etherscan 的工作原理是艰难甚至是不可能的。

目前为止用户唯一可控的是当钱包记录可在上述区块链浏览器中检查的交易哈希时

因此，如果用户（尤其是非技术用户）无法通过查看UI来识别 Dapp 和普通的 Web 应用程序，也无法验证他所看到的内容或与之交互的情况，实际上与区块链有关，那么区块链应提供的无信任和透明度也就无从谈起

该类别中的 Web3 设计原则（TTT）提出了一种激进的透明度方法，可以使任何 Dapp 前端用户（甚至非技术用户）充分了解数据来源，了解交易在执行之前，期间和之后的影响， 最终信任手头的代码和服务。

回到cheatsheet

1 - （读取数据）数据源的透明度

用户需要能够通过查看页面来判断某个数据点或内容是否实际存储在区块链中。 让用户猜测并不是用户友好型应用的表现，并且让用户假设看到的“所有”数据存储在区块链中是不够的。 对于数据密集型Dapps，如分布式交易所而言，这一要求可能听起来很棘手，在下面的示例中会介绍相关的解决方案。

🔑🔑 Principles 🔑🔑 Dapp 前端应该：

➤阐明区块链数据和非区块链数据， ➤区分合同的地址 ➤将所有区块链数据链接到独立的区块链浏览器 ➤阐明哪些数据来自可信任数据源（∞链接> 5.代码透明度）

具体做法 使用css更改颜色/字体/形状以区分区块链数据并尝试在整个项目中保持一致并始终使用相同的“区块链颜色”

数据来源：为来自特定合同的数据着色

使用可扩展引用： 当悬停或单击区块链数据点时，可提供一个上下文扩展工具提示，其中包含有关数据点的更多信息，该信息应明确在区块链上的哪些位置可以找到数据

使用链接图标管理样式冲突 如果数据点既是“区块链数据点”又是指向dapp某处的链接，则有两种方法可以解决双重操作： 1-添加一个链接图标，一个跟随任何“区块链数据点”的图标，该图标提供可扩展的参考功能，同时保持链接的正常工作。 2-打开可扩展引用并在其中插入辅助链接（但考虑到这会产生更多摩擦，因为您要求用户执行2个操作而不是一个操作）。

使用链接图标管理样式冲突 如果数据点既是“区块链数据点”又是指向dapp某处的链接，则有两种方法可以解决双重操作： 1-添加一个跟随任何“区块链数据点”的链接图标，该图标提供可扩展的引用功能，同时保持链接的正常工作。 2-打开可扩展引用并在其中插入辅助链接（但考虑到这会产生更多冲突，因为这要求用户执行 2 个操作而不是一个操作）

打开上下文引用的链接图标示例。 这是将链接视图功能添加到 Dapp 中的某个链接

使用“链视图”模式和侧面板 对于像去中心化交易所这样的数据密集型接口或之前建议的市场视图可能意味着对大部分界面进行样式化，这会造成不必要的混淆。 要解决此问题，可以设想一个“链视图”按钮，当悬停或单击时，会暂时设置数据样式, 就像在页面上放置一个帮助用户查看哪些数据是区块链数据点的过滤器。

扩展开来，“链视图”也可以是一个侧面板，托管Web3设计原则中描述的许多功能。 在这种情况下，链视图面板可设置上述选项来设置区块链数据点是否可见。 在接下来的示例中，将看到链视图面板的更多用途。

带有数据来源选项的链视图侧面板

清晰地显示打开外部区块链浏览器的链接 如果链接要将用户转移到另一个页面，最好通过以下方式控制页面上用户的流量： 1 - 添加一个“clarifying”按钮，说明将要发生的事情：即“在Etherscan中打开” 2 - 为独立区块浏览器添加链接图标，并在UI中使用它

📌回到cheatsheet

2 - （写入数据）交易的透明度 用户需要知道数据将被写入区块链，特别是当它需要交换加密货币或代币时。 即使钱包对其进行警告，Dapp也应该在向钱包启动交易请求之前进行说明。

交易类型

在与区块链交互时会发生不同类型的交易，每种交易都会产生不同的后果 用户应该能够通过 UI 在不同阶段提供的信息来区分它们，甚至在启动事务之前

2.1 - 价值转移

2.1.1 - ETH
2.1.2 - 代币   2.2 - 函数调用
2.2.1 - 具有价值影响的合同方法
2.2.2 - 无价值转移的合同方法 2.3 - 工厂：合同生成功函数
交易数据和成本 事务通常具备附加一些数据的“有效载荷”（payload），例如将其传递给合同方法，这通常用于写入或计算在区块链中写入的内容

此外，向区块链写入数据通常会产生消耗，即支付交易的“gas 费用”，用户应该了解这两个概念及其内容

🔑🔑原则🔑🔑 Dapp前端应该：

➤（持久性）对不可逆转的行为进行说明（皆写作 Txs）

➤（价值）对涉及金钱或价值的行为进行说明

➤🌀（隐私）对需要用户识别的行为进行说明

这是最难实现的原则之一，因为任何写入的数据都可能有助于用户识别（直到ZTKSnarks），智能合约和web3开发人员可能不知道法医工具的当前和未来的复杂性，该解决方案通常是闭源的。 如果隐私是 Dapp 的主要功能，请考虑这一原则，并使用它来指导设计何时说明用户寻求隐私的潜在风险。

➤🌀（工厂）阐明在用户名中生成新合同的操作 此原则仅适用于帮助使用用户地址作为消息创建者的合同 Dapp ，特别适用于主网上的应用

所有交易指南： ➤🌀阐明并事先确认新的未来状态 ➤以人类可读的格式以及智能合约要求的方式显示正在用于交易的数据（∞链接5.代码的透明度） ➤阐明天然气价格的建议值以及如何覆盖Tx（∞链接9.Gas价格和交易逆转） ➤管理事务等待时间（∞链接> 6.Time / Wait 管理） ➤记录交易后，向用户显示交易的相关摘要以及如何访问历史记录（∞链接4.用户交互历史记录） ➤阐明不是交易的行为，以此确保安全

具体示例 使用css表示所有不可逆转的行为 例如使用红色作为警告/高亮颜色 添加一个微小的书面警告和按钮 即：注意不可逆转的行动>了解更多 使用双重确认： 在用户按下按钮之后和调用钱包/ MetaMask之前打开弹出窗口或吐司，您可以在其中通知用户所有影响并要求确认。 还为用户提供：

取消动作
不要显示弹出窗口（因为她是专家用户）这样做时告诉用户她最终可以在 Chain-View 侧面板中重新激活该功能。
阐明并预测未来的预期步骤 无论是使用微小的书面描述，标签子标题，还是使用向导都有更多步骤来完成动作。 在使用向导的情况下：

向用户显示后续步骤的编号和标题
允许用户了解正在发生的事情以及将要发生的事情（∞链接8.Newbie模式），并且应该将其功能置灰，以免混淆将预览和实际动作混淆 向Chain-View侧面板添加选项 侧面板可以是许多这些警告的地方，也可以为交易提供检查员，定义
交易类型
与交易相关的数据
Gas 费用
所有其他相关信息（∞链接5.代码透明度）
📌回到cheatsheet

3 - （推送数据）智能合约事件的透明度 事件（Event）相当于 Web3 时代的通知

（以太坊）智能合约可以发出事件，用于在区块链中存储日志，并通过 Javascript 通知 Dapps 前端已发生的事情。

了解事件非常重要

事件中的日志(logs) 可以包含参数和信息
在区块链中永久存储，因此可以进行搜索
开发人员通常会使用事件（Event）来处理各种事务，例如在满足特定条件时发出信号或发生特定操作时,比如新用户成为代币持有者，进行存款或从 Oracle 接收数据等等

可以搜索事件对于记录一个 Dapp 的特定行为非常有用，并且可以了解自 Dapp 创建以来成千上万的区块中发生的事件

为了更好地理解事件的重要性，下面阐述一个小故事： 当 Dao 在2016年遭到黑客入侵时，我有机会与小组合作解决这个大问题的一部分：找出用户在 ExtraBalance 中欠下的以太币数目及其对应账户。 当用户在ICO期间购买Dao 代币时，根据费用表，不同数量的以太将进入ExtraBalance 该团队的两个成员，Nick Johnson和Bokky Poobah，使用“CreatedToken”事件来追踪与DAO ICO相关的所有交易，而我使用另一种更为艰难的方法，假设事件尚未实施，并开发区块链的解析器，一种取证工具，对于恶意或计划不当的智能合约非常有用。之所以这样做也是因为没有像“ReceivedByExtraBalance”这样的事件来确定交易部分。 有趣的地方在于虽然他们的脚本只需要几个小时，而我的脚本需要一天或更长时间;这是因为我的脚本需要遍历（重新执行）区块链中的每一笔交易，而由于事件日志，他们可以访问 “正确” 的交易 即便如此，我们三个人花了大约两个月的时间来将所有的余额归还给原来的所有者

这与Web3设计原则有什么关系？ 开发人员可以随心所欲地使用事件(Event)：通过事件来发送 Dapp 的重要信息，让前端用户访问智能合约中的事件。

质量较高的事件可以成为智能合约和 Dapp 的标志，它可以是透明的，让用户知晓它在内部的工作原理，不必担心智能合约是草率的或是恶意的

正如上面的 DAO 故事所述，缺少事件会迫使用户自我开发区块链解析器来了解内部发生的事情，这实际上是一项不可能完成的任务，因为她需要一个 Archival 节点(即全节点，full node)

此外，事件对于开发人员来说非常有用，可以创建多种类型的解析，通知和响应数据源，甚至独立于智能合约所有者/创建者。 前端用户也应该可以在无需编码的前提下使用此功能

Web3价值观：

如果需要查找，查看和验证数据需要花费大量的精力，则不透明
如果99％的用户不愿意查看，也不透明了[2]
🔑🔑原则🔑🔑 Dapp前端应该：

➤阐明并且用户最终可以访问所有事件，即使它们仅适用于开发人员

➤应用相关性：仅显示与当前用户相关的信息中断消息，但仍允许用户在单独的界面中检查所有事件

➤允许用户订阅，取消订阅或暂时不接收某些事件

事件是专用于合约的，因此这些是可能实现的简单建议。 此外，可以通过外部工具，服务，插件或库更好地实现这些想法，而不需要 Dapp 前端开发人员将所有这些“非核心”功能在 Dapp 中实现

示例： 设立一个用户可以访问的通知中心，这可能是 “链视图” 侧面板中的一个部分 为重要的消息使用 Toasts 消息提示框 创建过滤器以仅选择/取消选择某些事件或基于某些参数的自定义通知。   过滤器可以是：

包含以太币/代币
基于地址（我的/用户或其他地址或地址）
在 timeX 和 timeY 之间，blockX和blockY 等等 📌回到cheatsheet
4 - （历史）可访问且透明的用户交互历史记录 在用户与成百上千个 Dapps ，通证和链进行交互的未来，有一个清晰的历史记录，记录用户的每个交互过程是非常重要的   钱包存储了所有交易的历史记录，但这是一个开始，它一次只能用于一个账户，因此可能很难弄清楚您是否与其中几个帐户进行了交互

此外，除非建立额外的功能，否则钱包仍然很难广泛应用，例如，只过滤特定Dapp

Dapp肯定是用户友好的，可以帮助用户记住使用它进行的每次互动，就像用户可以在任何普通应用中回到“购买历史记录”一样

分布式交易所和 Dapps 会为每个用户生成数百或数千个事务，因此这一点尤为重要

🔑🔑原则🔑🔑 Dapp前端应该：

➤提供给定地址的所有交易历史记录 允许用户检查所有与智能合约（可能主要是类型2）进行的交互，即写入区块链并修改状态的交互记录

➤阐明存储历史的位置 提供给定用户的历史记录意味着在数据库上记录该特定用户的交易哈希，在远程服务器上或在用户的本地索引数据库(indexDB)中。 这当然是潜在的隐私风险，因此请注意隐私原则（∞link2.Transparency of Transactions）和代码透明度原则（∞link5.Transparency of Code），以向用户说明存储此数据的位置。

➤提供用于导航，搜索，导出和删除历史记录缓存的工具 示例 类似于事件通知中心，设置一个用户历史选项卡或专用页面， 在 Chain-View 侧面板内允许过滤不同类型的事务（以太币，代币，函数调用，合同生成） 允许按日期，从开头或日期之间进行过滤 可选的用户友好型设置：允许用户在事务中添加非链接注释字段，例如，如果用户想要简单地具有人类可读和可搜索的明文，则需要简单的提醒 可选：建立搜索字段，以防交互数目过多 即：去中心化交易所可能希望添加此类功能，以允许用户搜索仅与特定令牌相关的交易

导出：允许用户选择性地导出 csv 中的数据并进行其他操作，尤其适用于大型数据集

删除：允许用户从本地缓存中删除历史记录，但交易的真实历史记录既不是从钱包删除，也不是从区块链中删除

导入：仅当Dapp允许用户为每个事务添加自定义注释时，添加导入选项才是有意义的，否则可以从区块链中简单地重建信息

📌回到cheatsheet

5 - （代码和环境）代码的透明度 如果可以信任Dapp也意味着可以信任正在执行的代码 为了获得信任，Dapps 应了解其代码的所有方面

Web3 价值观

要使 Dapp 受信任，需先信任代码
对于受信任的代码，需要透明，独立可执行和可验证
🔑🔑原则🔑🔑 Dapp前端应该： ➤阐明正在使用的区块链 这是显而易见的，在 Dapps 激增的情况下,Dapps 在不同的区块链上运行不同的版本。 此外，对于Plasma，Polkadot，Cosmos和其他扩展解决方案，Dapp可能会跟踪其子链中的事务，这些子链嵌套在其他 plasma 链或 Cosmos Zones 或 Hub 树的深处 。用户应当知道他们的数据写入存储的位置，因此要知道技术性的变量（安全性，速度等）以及独立验证数据的位置。

➤阐明用于读写操作的智能合约的地址 链接到独立的区块链浏览器（∞link1.数据来源的透明度）

➤明确哪些代码是开源的以及在哪里找到它。

➤阐明代码运行的位置（本地或远程服务器） 这可能是实现最困难和最麻烦的事情之一，需要服务器上运行的部分中至少有一个页面解释运行部分及其原因，并在 UI 的相关部分指向它。 如果在第一原则（∞链接1.数据源的透明度）的示例中看到的“链视图”模式已经实现，那么这将是添加这些其他视图的好地方。   ➤阐明 web3 提供商/ 区块链节点（本地节点，Dapp 控制节点，Infura，MetaMask 或其他节点） 至于为什么这样做，是因为已检测的节点可以记录数据，例如 etherscan，这可能成为用户隐私风险的来源

允许用户切换到自己所拥有的节点 虽然这已经被像 MetaMask 这样的提供商所关注，但是这个原则适用于 web3 Dapp 因为它可以向特定节点广播事务。 此外，通过私有节点执行的事务可以更快地执行，因为它们可以避免公共节点队列，尤其是在众包等高需求事件期间。
➤阐明 Dapp 是在主网上运行还是在测试网上运行 虽然 web3 提供商负责处理这个问题，但要确保用户理解在主网上进行的操作（可使用∞link中的其他原则2.交易的透明度）

➤阐明从区块链上读取的数据来自 Oracles 可信数据源

关于用户友好型的补充 ➤允许自行执行代码 允许高级用户在发送事务之前查看函数调用，以便验证它并通过命令行重现该事务。 这似乎有点夸张，因为 Dapp 前端是为了简化用户并隐藏某些技术问题，但是一个持怀疑态度/偏执的用户会想要验证单个事务：如果区块链类似于分布式数据库，那么用户应该能够独立执行写入操作，并且在此期间 Dapp 工作状态不受影响

在代码极力争取透明的同时，Dapp 也应该争取在无信任的基础上进行验证 https://blog.wizsec.jp/2018/02/kleiman-v-craig-wright-bitcoins.html?m=1

Data Provenance的增强版本，用户还可以复制粘贴代码以自行检索数据

➤阐明智能合约所需的输入： 智能合约中的数字通常带有大量的零，这对用户不友好，并且很容易造成代价高昂的错误。 Dapp UI 对其进行简化是正常和可取的，较小的数字更易于理解且更不容易出错，例如 0 到 100 .但是，鉴于代码的透明性原则，用户应清楚地了解这些输入被 UI 简化的内容，并阐明，特别是 DIY 代码检查器，即智能合约的实际输入 在与 Jorge Izquierdo 讨论 Aragon Voting 应用程序时，提出了一个真实案例，令人非常困惑。 开发人员可以使用该案例提供的相同解决方案，并通过简单数字，科学记数法和智能合约期望的实际输入（全部为零）向用户阐明

示例 提供一个像服务条款或隐私政策页面一样访问的 “代码透明度” 页面 并在某些地方提供用户 github 仓库的链接 添加到 “链视图” 面板（第1章的示例中数据源的透明度）专门用于代码透明度的部分 ○相关信息：

正在使用的区块链，
区块链属性，尤其是平均区块确认时间（∞链接6.Time / Wait 管理）
是主网还是测试网
正在使用的 web3 提供商（允许切换），
合约地址
可能是合同的ABI的简化版本，只有代码实际调用的方法
如果代码的任何部分不在本地运行（文本说明和动机）
github 仓库的链接 ○开关，过滤器或选项：
显示带图标和通过更改颜色，服务器上处理过组件的数据
显示使用（“ 云到链 ”oracle ）链接图标和通过改变颜色来自 oracle 可信数据源的数据
如果有必要，请更改 web3 提供商
可在命令行上复制和执行的函数调用来调用事务的预览，对相关的输入进行注释
代码透明度面板和信息示例

📌回到cheatsheet

通用 Web3 UX 原则 以下原则不再与透明度和无信任直接相关，而是旨在解决基于区块链的分布式应用程序的使用和实现所产生的用户体验问题

6 - time / wait 管理 在可扩展性问题得到解决之前，事务是异步的，底层的区块链和当前的网络拥塞的情况下，需要很长时间才能处理事务并得到充分确认。

精心设计的 Dapp 需要阐明这些信息并管理用户的等待，直至得到确认

🔑🔑原则🔑🔑 Dapp前端应该：

➤🌀（管理用户期望得到的信息）在每次交易时明确底层区块链的平均区块确认时间和当前网络拥塞

➤🌀（管理等待时间）在等待时间内显示活性指标

示例 关于一系列用户体验， Dapp 应该： 阐明不同的 gas 如何影响其等待时间（∞link.9 Gas 价格和 TXs 逆转） 显示特定时间的警告 显示进度或等待图标，直到它被解决 如果事情花费的时间比平时长，请显示反馈和潜在原因及解决方案 即：“它花费的时间比预期的要长。 该网络目前拥挤不堪。   以下是您的选择：   - >等待X秒/分钟   - >添加更多 Gas 以加速交易   - >完成后收到通知 在任何情况下都会通知用户成功执行的操作 一旦操作完成，通过数据报告（即交易哈希）通知执行成功，并可以独立验证

📌回到cheatsheet

7 - 人类可读的哈希格式 在名称注册管理机构被广泛采用之前，用户必须处理长地址和事务哈希 这些只是关于如何使它们更具可读性的一些想法，同时保持完整信息的透明度

🔑🔑原则🔑🔑 Dapps前端应该：

⚠️🚧临时更新 2018-07-11 关于原则安全性的辩论。 几天后提供一个更好，更安全的版本🚧🚧️ ➤显示哈希的紧凑版本，但始终显示初始和结束部分 即：0xABCD ... EFGH 但请注意，这可能包含安全问题，因为 vanity 地址生成器可以在大约一周的时间内内生成 8 个字符的序列，

这有安全隐患，如 Tom Nash 在此处所述）>修改如下：

➤如果用户需要更简短的版本，请采用逆序形式 即使用0x ... EFGH而不是0xABCD ... （虽然它更具可读性，并且形式更好看，能看到前 4 个字符，但与0x ... EFGH相比，存在一个安全问题，因为前4个字符更容易暴力生成，就像 vanity url 一样，但是很难生成最后4个字符的完全匹配）

➤更喜欢使用4个字母的块而不是每个部分使用3个字母 即使用0xABCD ...而不是0xABC ...

➤在前面添加 “0x” 以表示它是一个哈希值

➤允许可选视图，其中整个地址可见

➤允许用户轻松复制地址

➤🌀尽可能使用缩写作为标题，缩写地址作为子标题

➤创建一个系统，允许用户轻松地将自定义的可读名称或文本与地址相关联 这些注释应该存储在用户的本地计算机上，而不是存储在服务器上（∞链接5.代码原则的透明度） 使用已知别名数据库（如 ENS 注册表或 Etherscan ）来获取已知合同和地址。

📌回到cheatsheet

8 - 新手模式 如果想要大规模采用分布式应用程序，则意味着需要大量无任何技术知识背景的人员，在不需要了解区块链及其术语的情况下进入该领域。   这不仅仅是出于安全原因（处理私钥）需要对使用人员进行教育，而且还要完全理解为什么区块链的属性是如此革命性的现象以及Dapps与其他应用程序的区别。

同样重要的是，这需要新的心理模型和多学科理解：价值互联网正在创造数千个受市场动态影响的象征化生态系统，这些生态系统通常在经济学，金融学和博弈论中进行研究;而群众不太可能精通或曾经接触过这些学科

因此，分布式应用程序应该努力教育新人并建立用户所工作的内容

先前的大多数原则都考虑到了新手用户，但开发人员应该考虑更多的事情

🔑🔑原则🔑🔑 Dapp前端应该：

➤🌀在交互中编入教育信息 Nick Neuman 非常好地总结了 Dapp 设计师的主要任务：“一个好的用户应用程序应把教育融入到产品体验中。这意味着以简洁有趣的方式解释用户为什么要做这件事，并帮助构建产品，以此确保用户操作的安全性。“

➤提供第二级别或更高级别的教育内容：区块链基础知识和 Dapp 特定术语 这不仅仅是新手加入时的原则，对所有应用程序，特别是那些具有内部或上下文术语或独特机制的应用程序来说，添加教育层是一种很好的做法：即如果正在建立代币管理应用程序，请不要假设用户知道财务以及每个术语的含义;相反，给予用户区块链的基础知识和金融的基础知识，至少要让用户了解正在使用的单词

➤🌀最小化并逐步增加用户需要学习的新事物和概念的数量 尽管区块链项目采用了许多激励措施，仍然必须面对任何软件服务必经的用户流失：用户会选择更简单的替代方案，特别是当 Dapp 要求太多。 因此，Dapps在向新移民提供教育内容时，应尽量减少对新词和概念的使用，特别是在通用公共页面（即主页）中，并逐步在参与用户的页面中显示更多学习内容（即用户仪表盘）。 这也可以通过使用更简单的语言，避免使用术语，并使用类比来解释用户可能已经熟悉的知识的复杂新信息来实现。 作为一个例子，看看 Spankchain 如何创建卡的概念，以避免解释支付渠道

➤提供“专家级别的解释” 揭开 Dapps 功能的含义，它们如何相互作用以及专家如何思考所带来影响的神秘面纱。 专家对特定事物的了解程度有多少？ 他们将如何解释数据？ 他们将如何采取行动？ 他们会做出什么选择？ 这些问题的答案可以作为 Dapp UI 中的建议内容 例如，预测合适的 Gas 价格（∞link9.Gas价格）以指示交换特定代币的合适时机（仅用于举例）

➤注意上下文的内容要紧凑 组织不同页面内的片段，临时弹出窗口，在另一个选项卡中打开更详细的信息会分散用户的注意力。 学习时，应当允许用户快速并“就地”学习，而无需更改页面并忽略他们在做什么。

示例 对所有的命令添加子标题（并参考其他原则来预测将要执行的事务∞链接2.交易透明度） 学习模式设置 添加到“链视图”或UI的其他部分，可以打开和关闭的开关（“通用问号”按钮）以及启用或禁用学习功能 词汇表弹出窗口 使用字典中提供的术语时，显示链接图标，单词后面的图标，如果单击或翻转，则显示带有指定信息的上下文弹出窗口 在某些情况下，弹出窗口还应提供“了解更多”的机会，这将在词汇表选项卡中打开的“链视图”中打开另一个选项卡或侧边栏。

词汇表页面 在链视图或其他页面中，Dapp 应该提供一个页面，其中包含所有区块链和 Dapp 的特定术语，以了解其机制。 此页面应从词汇表弹出窗口重定向，而不是直接链接。 在任何向导中，能够快速转发到后续步骤是聪明的做法，用户可以看到即将发生的事情，尽管在完成前面的步骤之前，所有布局都应该显示为灰色并禁用。 对于任何ui而言，这都是一个很好的原则，不仅仅是Dapps。

📌回到cheatsheet

9 - Gas 价格和交易逆转 Gas 是新手最容易混淆的事情之一。 即使顾名思义，也很难想象用户所拥有的服务在计算成本基本是免费的。

更重要的是，当用户第一次遇到 Gas 时，他们不知道如何定价，也不知道如何选择 Gas 的合适价格

现在 Gas 都是由发放交易的钱包进行处理 ，但这个原则对于钱包设计师和所有需要用户选择 Gas 价格的人来说仍然有效。

幸运的是，开发人员可以使用像以太坊 Gas 站这样的工具，它提供了一个方便的API

🔑🔑原则🔑🔑 Dapps前端应该：

➤阐明 Gas 和 Gas 价格 （∞链接8.新手模式）

➤给予合理的 Gas 价格区间，并阐明上限和下限范围内的近似值 这些是当前处理网络拥塞的函数，最佳解决方案是查询当前以太坊 Gas 站API https://ethgasstation.info/json/ethgasAPI.json以建议这些范围界限。 重要的是向用户说明这些建议值在将来可能会发生变化

➤🌀显示转换为法定货币（FIAT）的 Gas 值

➤允许交易逆转：如果用户发送了低 Gas 的交易，应该向用户说明 （∞链接 6.Time / Wait 管理）

交易启动后无法取消
唯一的解决方案是使用相同的nonce和更高的 Gas 价格广播另一个交易
提供自动恢复 tx nonce 并以更高的 gas 价格发送它的选项。

📌回到cheatsheet

DDP:去中心化设计原则 去中心化是一种全球范围内新的强大形式。 这是第一次由大量自我主权的个人领导，这些个人围绕着无国界的思想，自我管理组织和分布式市场体系。

这些设计原则只供初步考虑如何让用户感觉到自己是社区的一部分，并进行更深远的思考。 它们只是开发人员处在正在创建的分布式社会的更大背景下开始全面思考 Dapps 功能以及出现的新 UX 需求的提示

10 - 社区意识 Dapps与应用程序不同，因为它们是分布式的：即使有些是针对个人的服务，并且其互动相对比较单调，但仍然是为全世界的一大群人制作的。   在这些Dapps中，对社区的归属感尤为重要，因为用户需要与去中心化的产品相绑定。

这并不意味着沉浸在 Dapp 社交网络中，尽管某些用户会受益于与社区聊天中更紧密的整合。

毋庸置疑，这些想法对于 DAO 来说非常重要

让用户在实现某些目标时考虑的不仅仅只是他们自己

🔑🔑原则🔑🔑 Dapps前端应该：   ➤阐明社区中其他成员的数量 ➤阐明谁是其他成员（选择适当的类别） ➤阐明社区的组成（即分组及其对项目的权力架构） ➤项目的更大使命以及社区成员的参与如何有助于实现

示例 提供登陆仪表板，其中包含有关代币持有者，Dapp 或 DAO 成员数量的统计信息 采用透明度原则，通过分析区块链，显示用户可以获得的所有信息：

代币分配，
采用时间图，
自XX区块和yyyy-mm-dd以来的代币持有者   等等
在DAO中考虑使用相关内容（如果可用）来丰富信息，例如：

种类的成员（即加密小猫中的育种者与非育种者，或者 音乐 / 艺术 Dapps中的音乐家和听众，如 UJO music ，stakers 与非 stakers 等）
staking 分布统计
地理位置/时区
性别，年龄 （但前提是它确实对您的社区有意义，并且不会对 Dapp 产生不利） 显然，要搜索与项目相关的类别：例如，在DAO中，性别和年龄不是相关信息，甚至会对创建无权和无偏见社会的想法产生反作用，但也许它们与 SpankChain 等项目非常相关 允许用户选择自己的标签，类别，生物描述等：每个成员可以在不同的项目中具有不同的身份。这已经暗示了将来会出现的有关身份的其他原则。
📌回到cheatsheet

11 - 其他未来设计原则 之前的原则需要更多关于身份，声誉和治理的想法。 前两个在许多社区驱动的应用程序中普遍有用，但它们将是Token Curated Registries（TCR），许多 DAO 和其他加密原语的基础

这些原则需要他们自行分析，这个帖子已经太长了

在未来，我将分析Web3设计原则：

身份和声誉
治理
钱包
交易
ICO和代币销售机制
代币机制
下一步 很明显，这些Web3设计原则中提出的“极端透明度”的要求给 Dapp 开发人员提出了极高的要求，如今开发人员更专注于解决项目的许多其他部分。  

像库一样的 Bootstrap 显而易见的是，应该有一个标准工具集，开发人员可以插入到 Dapps 中，并将调用连接到web3库，并为用户免费提供这些服务。 我正在想象 Web3 时代的类似 Bootstrap 的库（“Chainstrap” 有点太难了）

独立的浏览器插件 应该有一个独立的工具可以为用户提供 Dapp 创建者自选的Web3设计原则; 一种“透明执行者”，可以通过一些原则来识别恶意或草率的 Dapps 在这种情况下，适合创建一个浏览器插件，将其代码注入 Dapp 并提供链视图功能，甚至可以快速认证 Dapp 的透明度和可信度。

定制服务 此外，在这些原则中，服务板块尚具非常高的潜力，即使在如今的商业环境中也尚不存在

✋如果您有兴趣开发上述任何一项，或只是有一些想法，🙏 或者是一个赠款组织，并认为它可以适合您当前的目标， 👉请联系b [at] likuidlabs.com，或发送电子邮件至twitter @lyricalpolymath👈

[1]其他“区块链”+设计文章

区块链设计原则 - IBM设计 这是迄今为止关于该主题的最佳文章。 由Sarah Baker Mills撰写，他是IBM的前设计负责人，现在是Consensys的设计总监。 她很好地提炼了Web3设计原则中出现的一些原则，只是名称上的不同。 她谈到数据暴露，一致性，反馈，预测错误和主动引导。

区块链和设计 - Hacker Noon 21.co首席设计师Matt Storus 在采访中谈到设计师应该做的挑战和一些想法

区块链的用户体验 一个通用的帖子，区块链及其设计方面的挑战 设计如何帮助区块链 - Spark 关于这个领域的设计师应该考虑的一些宏观想法 设计区块链：启动以太坊智能合约应用程序 围绕为投资平台设计更好的体验的研究案例，以及一些改善 ICO 参与的想法 [2]我知道这些假设是一种谬误，但我仍然使用它们，因为它们是一种有用的简化，并指出：非技术用户不能以一种简单的方式自行验证数据， 因为信息不透明，以至于透明度变成闪闪发光的海市蜃楼。