Share Dialog
Share Dialog
Subscribe to fhkyj7
Subscribe to fhkyj7
<100 subscribers
<100 subscribers
第一次玩StepN时，用户需要使用邮箱账号注册。完成注册后，需要导入/新建一个加密钱包，如果导入原有助记词（使用过有资产的钱包），会很担心助记词触网的安全问题。
如果新建一个钱包，也有同样的热钱包备份不当的安全担忧。这是加密老用户的担忧，而对于一个web3新人，什么是助记词，如何安全保管助记词，都是非常陌生且没有概念的，非常容易导致资产丢失。
使用Mirror发布文章时，要链接钱包进行签名认证，它提供了一个比较友好的“remember me”功能，在一次签名后，可以在一段时间内（大概一周）不需再次签名，一定程度上方便了用户，但对于月更的我来说，每次都需要链接硬件钱包去签名，实在觉得繁琐，仅仅发布一个文章而已。
更极端的例子，是目前的一些社交类web3应用，当需要关注人、发表评论等操作时，都需要验证签名，为了方便大多人会专门搞一个热钱包（有安全意识的）。
但有些应用，由于涉及历史行为的标注以及空投等诱惑，迫不得已还是要用老地址去做验签，这种地址往往有很多资产在里面，如果签名不注意，就容易导致授权过大，进而导致一些不必要的资产损失。
如果有大额资产参与DeFi，常常会使用多签、硬件钱包等相对安全的基础设施。这些地址也可能会被用来交易NFT，而NFT交易很多时候需要签名授权。目前的应用签名信息不够直观，用户大多不太理解具体签名的内容，这很容易导致签名授权过大从而被黑。
这几个典型的场景，总结起来就是目前web3身份验证存在的不易用、不便捷和不安全等问题。
这些问题出现的本质原因，大多是因为身份和账号没有被清晰界定，大部分情况下钱包即被认为是账号，又被认为是用户的身份。
而去中心化非托管钱包的发展，实际远远无法适配当前的web3发展速度。当DeFi出现时，我们采用这种模式还感觉不到太多问题。而当越来越多非金融类去中心化应用出现时，这种认证方式就会凸显诸多问题。
早期我们使用网页类web2应用时，大多采用账号+密码的认证方式访问。为了方便很多网站设置的都是相同的密码（这很不安全）。
随着移动应用的普及，慢慢我们习惯了手机号+验证码的认证方式。即便是网页端，也慢慢的支持了这种验证方式。
而为了更方便，我们的很多应用都使用了基于微信/手机号一键验证等验证模式，密码几乎不再被使用。
随着生物识别技术的发展，现在很多设备也都在采用刷脸、验证指纹等认证方式，验证码也在不断的被更新替代。
web2的身份验证正在往安全便捷的无密码认证方向发展。
无密码认证要比账号+密码的方式安全很多，由于账号+密码的方式存在弱口令问题和大量的被泄露数据，黑客可以利用大数据+撞库等方式破解。
如果有好的安全习惯，目前的移动应用大多很难被盗。配合使用1password等应用（做到一应用一密码），对于需要设置密码的应用也相对比较安全。
再看金融类应用的认证发展，最早网银很不方便，要使用密码卡转账。后来发展为使用usbkey的验证模式。
对于个人用户，现在手机网银几乎与其他非金融应用是一样的体验，手机号+刷脸认证，刷脸/验证码转账等等，非常方便。
这也有一定安全隐患，如果手机被黑了，存在手机里银行账户被盗的风险。
对于企业用户，目前usbkey（数字证书）的验证方式依然延续。而像银行间通信，大多采用点对点加密的方式。
很多初次使用web3应用的用户都会发出一个疑问，为啥这应用这么难用？最直观的就是大多是网页端访问，而且用户认证普遍不够友好。
难道web2中已被广泛采用的友好且安全的验证方式不能应用在web3么？
这里我们就要说一下web3与web2最重要的一点不同，就是用户资产的自主可控（可拥有）。
web2中，数据和资产都在中心化平台端，实际用户很难拥有自主权。
而web3中，去中心化的属性让用户从密码学角度拥有了自主权，your keys，your coins！
这也是为什么web3应用的认证方式，是让用户自主签名的原因。因为这些信息只有用户自己拥有。
我们常用的web2应用，每隔一段时间都可以重置密码以保证安全性，避免密码丢失导致的信息泄露。
如果发现账号被盗了，我们也可以及时修改密码，或者通过申诉等方式找回账号。
这种情况下，我们的账号仍然可以继续使用，跟我们账号关联的其他内容、数据和应用，都不需要重新授权或链接。
而对于去中心化钱包，一旦助记词/私钥丢失，这个钱包就没办法再使用了。因为只要有人知道这个助记词/私钥，就可以动里面的资产，就可以验证各类应用。
在web2中，账号被盗一方面可以申诉找回，另一方面也很容易进行各类禁用操作，只要有足够证据，就可以对可能的风险进行中心化的处理。比如向不同平台申诉，添加黑名单等等操作。
而在web3中，目前还没有一个能有效针对被盗账号的防范措施。一旦私钥丢了，这个账号就不再可用。但随着越来越多应用对身份行为的重视，我们很多的链上行为都与账号地址有关，一个用了很久的地址，或许就是一笔可观的财富。如果弃之不用，就非常的可惜。
是否有一种方式，能让我们像web2更换密码一样，在不变更账号（公钥地址）的情况下，对web3的钱包助记词/私钥进行自行更改呢？
目前在国内有很多面向个人用户的多账号分离/身份聚合的应用场景。
比如我们在使用共享单车时，有时会用支付宝扫码开锁，有时候会用微信扫码开锁，经常自己都没留意，但都能打的开锁。
各种共享商品，只要上面有个码，我们就会下意识的直接用微信/支付宝去扫，租充电宝、电车、雨伞等等。
这些应用使用起来非常方便，不需要我们注册任何账号，也不需要提供大量的个人信息，只需要进行一次授权即可。
在这些场景里，租借各种设备时，我们实际使用的还是这些应用本身的账号，而这个账号是通过身份授权产生的。
我们的大量身份信息和行为，都被聚合在一个叫“芝麻信用”/“微信支付分”的系统里，这个就是我们在互联网世界的聚合身份。
它是一套信用评价系统，拥有我们的各类身份数据和信用评级。不同应用通过与它的集成，可以申请一个授权，读取我们的身份，并创建临时的账号。
只要我们的信用能达到这些应用的设计要求，我们就可以平滑的使用。
对于企业级的应用，一个员工往往也会使用几十套各种不同系统，如果每个系统都有独立账号，记忆起来非常不方便。大多员工也都习惯用一样的密码，这样很不安全。
为了解决这一问题，有专门服务于企业级身份管理的解决方案IAM。能提供一套便捷安全的单点登录和统一账号密码系统，既解决了安全问题，又让员工使用系统更加便捷。
像以上这样的使用体验，在web3中也是被需要的。我们希望在玩游戏，体验社交应用，参与DeFi挖矿时，都有不同的账号，但他们都可以使用一套方便的方式进行统一的安全的管理。
既能做到资产在不同账号的隔离，也能做到身份在不同账号的互通。我们自己可以决定像外部展现何种身份，可以控制哪些身份是显性的，哪些是隐形的，以及他们之间的行为关系。
大部分的互联网用户都没有密码管理的安全意识，常常使用一套密码打遍天下。被用最多的安全保护措施就是不使用，比如不使用网银等等。
移动应用认证技术的发展演化，一方面是为了平台应用能有更大的网络效用，另一方面也切实的提升了用户使用的安全和便捷性。比如验证码+刷脸+风控等方式，让一般的密码泄露很难造成严重影响。
而web3应用，将身份主权交还给了用户，每个人对如何管理密钥在知识和技能上有着非常大的差异。
即便是一些老韭菜，也经常范丢失私钥的错误，不小心被钓鱼或是由于电脑被黑导致热钱包被盗。
使用硬件钱包、冷钱包、多签钱包的门槛更高，一般对于没有技术背景的用户，很难真正掌握这些钱包的安全使用方法，一不小心有可能自己反而把密钥搞丢。
web3这种不友好也不是很安全的密钥管理方式，切实的阻碍了很多人参与web3应用。
在web2中，我们可以通过1password、google密码管理等程序帮助管理密钥。但
助记词和私钥的使用大多比较强调离线备份，或者存放在硬件钱包里，或者采用更加安全的多签等技术。这些对于专业用户来说还好，对于web3用户来说就有一些难度了。
我们是否可以像web2那样保管密钥？不需要抄写，不需要硬件。即安全，又可以快速的恢复？
对于不同的使用需求，可以有不同的密钥管理策略，大额资产可以使用专业级安全方案。社交应用就使用一些便捷的方法，这样的角色授权分离，也让我们在使用不同应用时不至于过多的担心安全和隐私问题。
前面提到的很多问题，以及相对应的解决方案，我们目前看有一些web3项目已经在试图解决。
如果想让web3的使用体验与web2类似，个人认为需要合约钱包的大范围应用，这会实现目前很多不能实现的体验。比如恢复密钥、无费用交易、多账户风险隔离等等。
ERC4337是以太坊关于账户抽象的一个提案。它的提出主要目的是在不更改共识层协议的情况下，将用户账户升级为合约账户，这样做会带来非常多的好处。
目前，以太坊的账户类型分为外部账户（EOA）和合约账户。ERC4337的账户抽象方案，提出将两种账户类型减少为一种，即只保留合约账户。
ERC4337实现的账户抽象方案，可以为用户带来以下体验提升：
支持社交恢复：这个方案支持用户为钱包账户设置多个守护者，可以在丢失密钥的情况下帮助恢复钱包密钥。守护者可以是用户拥有的其他安全钱包、家人或朋友，甚至是第三方机构。
这个功能可以让用户的钱包账户更加安全，避免由于不理解助记词/私钥原理，或保管不善而导致的意外丢失。可以像web2一样管理应用的账户，在发现不安全因素或丢失密钥时，对钱包账户的密钥进行找回和重置。
支持代建账户/代付手续费：这一功能可以让应用帮助用户支付创建账户的gas费，也可以帮助用户代付交易手续费。甚至使用任意的ERC20代币支付交易手续费。简单说用户不需要自己入金就可以完整的体验web3应用。
这对普通用户来说非常有效，他们不需要支付创建账户的费用，甚至一些交易也不需要付费。这可以实现0门槛用户引流，并为用户建好安全的web3钱包。对于游戏和社交类应用，尤其好用。
支持账户升级：账户抽象的钱包是由智能合约控制，因此可对合约功能进行升级，可实现用户高度可自定义的能力，比如简化/个性化签名算法等。
对于ERC4337的实现，vitalik给出了一个路线图，其中包括：
短期：
让ERC-4337投产，支持将EOA升级为智能合约账户
支持ERC4337账户的易用的浏览器插件钱包
实施对Layer2友好的功能，短期在Layer2中推广ERC4337应用
中期：
实施Verkle树，降低gas成本
添加可选的EOA到ERC4337的转换
添加crLIst逻辑
长期：
考虑强制实行EOA转换，和单一的ERC4337账户
Web3Auth提供了一种与web2类似的社交认证方法，可以让web3认证保持与web2一致的使用体验。
Web3Auth是一项toB的应用，需要应用程序自主集成和配置后，用户才能体验到相应的认证体验，包括：
主流社交帐户登录和无密认证：用户可通过 Google、Twitter、GitHub 和其他 OAuth 提供商进行注册。用户还可以通过发送电子邮件的方式，进行无密码设置的注册流程。
支持Web3 钱包与密钥管理：可授权用户使用自主选择的钱包或密钥管理。比如用户可以使用他们现有的钱包登录或选择密钥管理（导入助记词），并将其直接连接到应用程序。
web3auth可以为用户提供类似web2的注册和认证体验，只需要通过第三方社交认证即可完成。
同时，web3auth还支持非托管的公钥基础设施（SSS 2/3 Shamir's Secret Sharing），这种方式极大方便了不懂管理密钥的用户，同时做到既是非托管钱包（用户完全自主掌握资产），又无需用户自行保管密钥。
如果觉得这种非托管方式不够安全，用户也可选择采用自己常用的钱包进行链接登录，比如ledger、phantom等。浏览器插件钱包keplr就是用web3auth扩展，用户可自行体验。
UniPass是多链统一加密身份应用，提供基于电子邮件的非托管社交恢复钱包解决方案。可以通过无密钥的方式控制用户的加密身份。还可以通过加密方式验证多链地址甚至社交帐户。
在前端功能上，unipass与web3auth类似，都有提供社交认证、社交恢复钱包等功能。相对已实现功能，unipass的2022年产品规划中提到的能力，与本文锁期望的去中心化身份演进有很多契合之处，其中包括：
web3身份聚合：基于密码学实现多链多账户的聚合。通过这种聚合方式，可以将用户在不同链上不同地址的行为聚合到一个身份ID中，实现信任的传递。简单说就是可以最大程度提升用户的链上行为评分。
web2身份验证：在智能合约中提供验证电子邮件地址、Twitter 账户、Discord 账户的能力，从而在 Web3 中原生提供 Web2 身份信息。
单点登录与访问门户：通过使用unipass id，进行多应用的统一登录。并为用户提供统一的web3门户导航。
身份标识对于身份识别非常重要，web3中每个账户都是一长串类似乱码的字母+数字，这难于记忆和识别。
ENS是一个基于以太坊区块链的分布式、开放和可扩展的命名系统。其推出的xxx.eth服务，将可读名称映射到了0x123xxx...的标识符，这在一定程度上缓解了这种识别困难。
Nametag 的目标是成为建立在区块链上的通用命名服务，用户通过铸造、存储、交易和使用唯一命名的 NFT 作为他们的通用用户名。
Lens 是Polygon上的 Web3 社交图谱协议。它的目标是形成一个完全可组合的、用户拥有的社交图谱。该协议从一开始就采用模块化设计，允许第三方基于协议开发新功能，同时确保用户拥有的内容和社交关系不可变。
其中ENS和Nametag是想成为基础命名服务让其他应用都来引用和适配。而Lens是想做社交基础设施，自带的xxx.lens有点类似微信名。最终哪种方式会在web3中更受欢迎，还有待时间验证。
对于web3用户来说，相对web2有一个更为重要的需求是自主的安全性，一切身份应该是建立在自主可控的安全基础之上。
相对于一个简单助记词导入的metamask热钱包，硬件钱包会更安全。避免了助记词被黑、钓鱼等风险。
在硬件钱包之上，还有更安全的多重签名解决方案，主要面向组织/社区/大额资金的管理需求。
对于一般个人，硬件钱包就已经相对比较安全了。但对于组织而言，还要考虑单点风险、作恶风险、授权风险等等，因此采用多签会更符合大额资金安全管理的需要。
Gnosis Safe 是一个可在多链运行的智能合约钱包，需要最少人数批准交易才能执行（M-of-N）。
Safe是一个智能合约账户，提供的能力包括：多签、限制转账金额、白名单转账、捆绑交易、紧急冻结/恢复账户、预设条件触发操作等。
上文的大量铺垫，是为了能更好的提出一种架构。它能更好的帮助用户进入web3应用，同时能获得更大的安全性和更好的体验感。
在web3里，钱包、账户、身份的概念有些模糊，没有清晰区分，往往钱包就是账户，账户被当做身份。
实际身份是一个集合，而账户是我们使用应用的具象载体，是身份的外延。而加密钱包是我们账户的一种载体和验证方法。
去中心化身份可以被分为三个层次，分别是：外显身份、代理身份和主权身份。
代理身份是一系列专属功能的账户，比如社交账户、游戏账户、交易账户、DeFi账户、匿名账户等等。
在这个模型中，所有的代理账户都可以是主权账户控制的合约账户，在发生危险时可以使用主权账户重置密钥，避免资产损失。同时可以延续各种行为画像。
这些代理账户是用户不同身份角色的代理，他们之前拥有独立用途和安全边界。避免使用一个账户什么都做，在安全的基础上又能提供便捷的体验。
比如社交账户中没有资产，专门用于登录各种应用，转评赞。游戏账户专门用于玩链上游戏，跟NFT账户可以共用或是分离。而NFT账户有可以专做一个貔貅账户，只买不卖，避免被黑。当要卖时再临时授权挂单。
为什么要采用这种按照角色分离的账户设置？
实际我们在使用web2应用时，大多时候也都是每个应用使用了不同的账户，他们之间没有统一的联系，账户名一样也是我们的主观选择。
而社交登录流行后，我们大多采用微信、gmail等认证方式，这种实际也是授权在应用中建立了一个新的账户映射，而不是直接使用gmail等作为账户主体。
在这个模式下，微信和gmail更类似我们的主权身份，他们可以恢复我们在不同应用中被忘记的账户，或是重置这些账户的密码。
角色分离的好处，是可以将风险隔离，可以提升使用不同应用的体验。我们不需要每次关注人时，都打开硬件钱包授权。而在需要操作资产时，又可以进行更复杂的策略授权，避免不小心或恶意的被盗。
使用代理账账户，我们会担心代理账户产生的行为无法共享，会降低我们在一些场景下的评级。这个问题实际可以通过外显身份的设置来解决。
外显身份是一系列凭证、标识、行为、关系、声誉的集合。
我们可以简单的理解外显身份就是一个个身份标签，主要作用是方便外部关系对我们的身份进行标识。
比如ens、lens等就是一个标识的外显身份，他们的作用是在社交关系上让身份更加易读。
poap是一类行为轨迹的外显身份，它主要是标记我们参与了哪些活动，类似的还有galaxy、rabbithole等。
在vitalik的SBT论文中，提到灵魂绑定token的很多用处，实际都是这种外显身份的能力范围。比如我们的社交关系、信誉、学历证书等等，都可以采用SBT的方式，与我们的身份进行绑定。
在实际应用层面，外显身份实际可以与代理身份合一，他们可以就是同一个账户地址，只是在逻辑层面加以区别会更好的为用户提供服务，或是便于应用进行设计和体验提升。
比如有些用户更加注重安全和隐私，那么这种外显身份就可以是独立的账户，专门用户外部的展示和关系构建。
而代理身份的行为映射完全可以通过隐私计算完成，既可以让我们的身份更像一个整体，又可以让用户可以灵活的控制向外部展现哪些身份特征。更进一步，我们可以灵活的构建多个外显身份，可以有更真实的，也可以有更匿名的。这样会降低用户使用的心里门槛。
在技术层面，要实现这种设计，目前的做法可以采用链上代理的模式，类似在链上签署一个授权，记录代理身份和外显身份的授权关系。一旦外显身份有什么问题，可以重新签署授权去更新或禁用身份行为的授权。听橙皮书关于DID那期播客，有讲到unipass就是采用了这种链上授权模式。
另一种更隐私的方式，可以采用合约账户+零知识证明的方式，以一种外部无法获取直接关系，而可以证明用户的身份不是伪造的方法，来实现这种身份属性的关联和外显。
采用这种外显身份与代理身份分离的设计方式，直观好处就是让用户的微信账号与银行账号分离。而不是别人知道你的微信号，就可以直接看你银行资产，甚至可以看你的钱从哪赚的，怎么亏的。
Not Your Keys, Not Your Coins.
这是web3最重要的基础，是个人资产神圣不可侵犯的保障。
对密钥的安全管理，一直是参与加密游戏的最重要一课，很多人因为保管不善而损失资产。
而如何安全的保管密钥，相对来说也是一件比较专业的事，新用户很难短时间掌握，需要大量的实践和很多次突破心理防线，才能真正自己安全的用非托管钱包管理资产。
密钥就是我们的主权身份，它宣誓了一切都是自己可控的。而不像web2那样说被禁用就被禁用。
而密钥的安全管理，一定是采用去中心化非托管的方式。这让我们能随时对自己的账户有控制权。
如果是个人使用，到硬件钱包这一层已经相对比较安全。如果是一个组织/社区来使用，可以采用多签的方式。
在未来架构中，这一身份可以是我们最不常使用的身份。只需要在创建代理身份时，用它来授权即可。当代理身份存在风险时，我们可以用它来充值代理身份的密钥，确保一切资产都在自己最终的可控范围。
对于web3新人，这种主权身份实际也可以采用第三方服务来实现。这是一种基于去中心化非托管的方案，比如像web3auth的SSS方案。这也降低了新人使用密钥的门槛。
以上提到的三个身份层次，他们实际上可以是辩证统一的整体，极端情况他们就是一个地址而已，所有身份都汇聚到一个公钥地址，目前很多用户也是在这么使用。
但这样的应用方式不够安全，很多人因此丢失了资产。由于很多心理阻碍，也无法真正让各类账号很好的组合起来，让一些本是积极建设的用户，在链上评分上不会很好。
目前的身份账户体系，并没有像web2那种更好的服务于用户。在web3，最重要的就是资产所有权问题，而用户与链上资产的关系，就是通过身份来桥接的。
只有处理好身份的关系，才能更好的让用户使用链上资产，使用各种web3应用。
通过将去中心化身份进行分层设计，一方面可以让专业人做专业事，各项目如果能围绕一个大的共识方向去做，也能更快更好的实现高度可组合的身份产品矩阵，真实的让用户得到实惠。
另一方面，也是为了能让用户更好的理解web3的身份账户概念，在先进来的前提下，通过更多的使用来慢慢了解和熟悉身份的安全管理。
因为web3的身份是属于个人的，因此需要我们自己对自己的身份资产负责。
最终，我们其实拥有的是一个身份集合（钱包账户集合）。
在上面的举例中，看似有很多身份概念很复杂。但实际如果有这样的应用，它可以将这些元素汇聚在一个应用中，让用户实际没有这些复杂概念的感知，只是去用就好了。
要达到这个理想化的架构，我们要做哪些事：
专业化web3身份认证服务商
toB先行，各DAPP采用web3身份认证组件
标准化认证服务、接口和流程
易用化用户注册、认证流程
提供代理账户能力，实现账户间的身份授权（链上）
支持浏览器插件的合约钱包
支持直接在web3的移动应用采用社交化认证
大量web3应用对合约账户的支持和安全的密钥管理
面向个人用户的一站式综合服务
ERC4337的实施，实现账户抽象
安全多签和硬件钱包的普及
去中心化非托管的密钥基础设施
对于个人用户，我们可以做些什么：
基于现有条件，划分自己的账户角色
使用不同角色的账户参与不同类型应用，风险隔离
安全保管好助记词/私钥，学习相关知识
尝试使用新型web3认证基础应用
对于专业身份认证、DID、社交等应用可以做些什么：
提供更安全的合约账户功能
尝试提供代付注册、交易费等能力
尝试向web2渗透认证能力，甚至是替代
第一次玩StepN时，用户需要使用邮箱账号注册。完成注册后，需要导入/新建一个加密钱包，如果导入原有助记词（使用过有资产的钱包），会很担心助记词触网的安全问题。
如果新建一个钱包，也有同样的热钱包备份不当的安全担忧。这是加密老用户的担忧，而对于一个web3新人，什么是助记词，如何安全保管助记词，都是非常陌生且没有概念的，非常容易导致资产丢失。
使用Mirror发布文章时，要链接钱包进行签名认证，它提供了一个比较友好的“remember me”功能，在一次签名后，可以在一段时间内（大概一周）不需再次签名，一定程度上方便了用户，但对于月更的我来说，每次都需要链接硬件钱包去签名，实在觉得繁琐，仅仅发布一个文章而已。
更极端的例子，是目前的一些社交类web3应用，当需要关注人、发表评论等操作时，都需要验证签名，为了方便大多人会专门搞一个热钱包（有安全意识的）。
但有些应用，由于涉及历史行为的标注以及空投等诱惑，迫不得已还是要用老地址去做验签，这种地址往往有很多资产在里面，如果签名不注意，就容易导致授权过大，进而导致一些不必要的资产损失。
如果有大额资产参与DeFi，常常会使用多签、硬件钱包等相对安全的基础设施。这些地址也可能会被用来交易NFT，而NFT交易很多时候需要签名授权。目前的应用签名信息不够直观，用户大多不太理解具体签名的内容，这很容易导致签名授权过大从而被黑。
这几个典型的场景，总结起来就是目前web3身份验证存在的不易用、不便捷和不安全等问题。
这些问题出现的本质原因，大多是因为身份和账号没有被清晰界定，大部分情况下钱包即被认为是账号，又被认为是用户的身份。
而去中心化非托管钱包的发展，实际远远无法适配当前的web3发展速度。当DeFi出现时，我们采用这种模式还感觉不到太多问题。而当越来越多非金融类去中心化应用出现时，这种认证方式就会凸显诸多问题。
早期我们使用网页类web2应用时，大多采用账号+密码的认证方式访问。为了方便很多网站设置的都是相同的密码（这很不安全）。
随着移动应用的普及，慢慢我们习惯了手机号+验证码的认证方式。即便是网页端，也慢慢的支持了这种验证方式。
而为了更方便，我们的很多应用都使用了基于微信/手机号一键验证等验证模式，密码几乎不再被使用。
随着生物识别技术的发展，现在很多设备也都在采用刷脸、验证指纹等认证方式，验证码也在不断的被更新替代。
web2的身份验证正在往安全便捷的无密码认证方向发展。
无密码认证要比账号+密码的方式安全很多，由于账号+密码的方式存在弱口令问题和大量的被泄露数据，黑客可以利用大数据+撞库等方式破解。
如果有好的安全习惯，目前的移动应用大多很难被盗。配合使用1password等应用（做到一应用一密码），对于需要设置密码的应用也相对比较安全。
再看金融类应用的认证发展，最早网银很不方便，要使用密码卡转账。后来发展为使用usbkey的验证模式。
对于个人用户，现在手机网银几乎与其他非金融应用是一样的体验，手机号+刷脸认证，刷脸/验证码转账等等，非常方便。
这也有一定安全隐患，如果手机被黑了，存在手机里银行账户被盗的风险。
对于企业用户，目前usbkey（数字证书）的验证方式依然延续。而像银行间通信，大多采用点对点加密的方式。
很多初次使用web3应用的用户都会发出一个疑问，为啥这应用这么难用？最直观的就是大多是网页端访问，而且用户认证普遍不够友好。
难道web2中已被广泛采用的友好且安全的验证方式不能应用在web3么？
这里我们就要说一下web3与web2最重要的一点不同，就是用户资产的自主可控（可拥有）。
web2中，数据和资产都在中心化平台端，实际用户很难拥有自主权。
而web3中，去中心化的属性让用户从密码学角度拥有了自主权，your keys，your coins！
这也是为什么web3应用的认证方式，是让用户自主签名的原因。因为这些信息只有用户自己拥有。
我们常用的web2应用，每隔一段时间都可以重置密码以保证安全性，避免密码丢失导致的信息泄露。
如果发现账号被盗了，我们也可以及时修改密码，或者通过申诉等方式找回账号。
这种情况下，我们的账号仍然可以继续使用，跟我们账号关联的其他内容、数据和应用，都不需要重新授权或链接。
而对于去中心化钱包，一旦助记词/私钥丢失，这个钱包就没办法再使用了。因为只要有人知道这个助记词/私钥，就可以动里面的资产，就可以验证各类应用。
在web2中，账号被盗一方面可以申诉找回，另一方面也很容易进行各类禁用操作，只要有足够证据，就可以对可能的风险进行中心化的处理。比如向不同平台申诉，添加黑名单等等操作。
而在web3中，目前还没有一个能有效针对被盗账号的防范措施。一旦私钥丢了，这个账号就不再可用。但随着越来越多应用对身份行为的重视，我们很多的链上行为都与账号地址有关，一个用了很久的地址，或许就是一笔可观的财富。如果弃之不用，就非常的可惜。
是否有一种方式，能让我们像web2更换密码一样，在不变更账号（公钥地址）的情况下，对web3的钱包助记词/私钥进行自行更改呢？
目前在国内有很多面向个人用户的多账号分离/身份聚合的应用场景。
比如我们在使用共享单车时，有时会用支付宝扫码开锁，有时候会用微信扫码开锁，经常自己都没留意，但都能打的开锁。
各种共享商品，只要上面有个码，我们就会下意识的直接用微信/支付宝去扫，租充电宝、电车、雨伞等等。
这些应用使用起来非常方便，不需要我们注册任何账号，也不需要提供大量的个人信息，只需要进行一次授权即可。
在这些场景里，租借各种设备时，我们实际使用的还是这些应用本身的账号，而这个账号是通过身份授权产生的。
我们的大量身份信息和行为，都被聚合在一个叫“芝麻信用”/“微信支付分”的系统里，这个就是我们在互联网世界的聚合身份。
它是一套信用评价系统，拥有我们的各类身份数据和信用评级。不同应用通过与它的集成，可以申请一个授权，读取我们的身份，并创建临时的账号。
只要我们的信用能达到这些应用的设计要求，我们就可以平滑的使用。
对于企业级的应用，一个员工往往也会使用几十套各种不同系统，如果每个系统都有独立账号，记忆起来非常不方便。大多员工也都习惯用一样的密码，这样很不安全。
为了解决这一问题，有专门服务于企业级身份管理的解决方案IAM。能提供一套便捷安全的单点登录和统一账号密码系统，既解决了安全问题，又让员工使用系统更加便捷。
像以上这样的使用体验，在web3中也是被需要的。我们希望在玩游戏，体验社交应用，参与DeFi挖矿时，都有不同的账号，但他们都可以使用一套方便的方式进行统一的安全的管理。
既能做到资产在不同账号的隔离，也能做到身份在不同账号的互通。我们自己可以决定像外部展现何种身份，可以控制哪些身份是显性的，哪些是隐形的，以及他们之间的行为关系。
大部分的互联网用户都没有密码管理的安全意识，常常使用一套密码打遍天下。被用最多的安全保护措施就是不使用，比如不使用网银等等。
移动应用认证技术的发展演化，一方面是为了平台应用能有更大的网络效用，另一方面也切实的提升了用户使用的安全和便捷性。比如验证码+刷脸+风控等方式，让一般的密码泄露很难造成严重影响。
而web3应用，将身份主权交还给了用户，每个人对如何管理密钥在知识和技能上有着非常大的差异。
即便是一些老韭菜，也经常范丢失私钥的错误，不小心被钓鱼或是由于电脑被黑导致热钱包被盗。
使用硬件钱包、冷钱包、多签钱包的门槛更高，一般对于没有技术背景的用户，很难真正掌握这些钱包的安全使用方法，一不小心有可能自己反而把密钥搞丢。
web3这种不友好也不是很安全的密钥管理方式，切实的阻碍了很多人参与web3应用。
在web2中，我们可以通过1password、google密码管理等程序帮助管理密钥。但
助记词和私钥的使用大多比较强调离线备份，或者存放在硬件钱包里，或者采用更加安全的多签等技术。这些对于专业用户来说还好，对于web3用户来说就有一些难度了。
我们是否可以像web2那样保管密钥？不需要抄写，不需要硬件。即安全，又可以快速的恢复？
对于不同的使用需求，可以有不同的密钥管理策略，大额资产可以使用专业级安全方案。社交应用就使用一些便捷的方法，这样的角色授权分离，也让我们在使用不同应用时不至于过多的担心安全和隐私问题。
前面提到的很多问题，以及相对应的解决方案，我们目前看有一些web3项目已经在试图解决。
如果想让web3的使用体验与web2类似，个人认为需要合约钱包的大范围应用，这会实现目前很多不能实现的体验。比如恢复密钥、无费用交易、多账户风险隔离等等。
ERC4337是以太坊关于账户抽象的一个提案。它的提出主要目的是在不更改共识层协议的情况下，将用户账户升级为合约账户，这样做会带来非常多的好处。
目前，以太坊的账户类型分为外部账户（EOA）和合约账户。ERC4337的账户抽象方案，提出将两种账户类型减少为一种，即只保留合约账户。
ERC4337实现的账户抽象方案，可以为用户带来以下体验提升：
支持社交恢复：这个方案支持用户为钱包账户设置多个守护者，可以在丢失密钥的情况下帮助恢复钱包密钥。守护者可以是用户拥有的其他安全钱包、家人或朋友，甚至是第三方机构。
这个功能可以让用户的钱包账户更加安全，避免由于不理解助记词/私钥原理，或保管不善而导致的意外丢失。可以像web2一样管理应用的账户，在发现不安全因素或丢失密钥时，对钱包账户的密钥进行找回和重置。
支持代建账户/代付手续费：这一功能可以让应用帮助用户支付创建账户的gas费，也可以帮助用户代付交易手续费。甚至使用任意的ERC20代币支付交易手续费。简单说用户不需要自己入金就可以完整的体验web3应用。
这对普通用户来说非常有效，他们不需要支付创建账户的费用，甚至一些交易也不需要付费。这可以实现0门槛用户引流，并为用户建好安全的web3钱包。对于游戏和社交类应用，尤其好用。
支持账户升级：账户抽象的钱包是由智能合约控制，因此可对合约功能进行升级，可实现用户高度可自定义的能力，比如简化/个性化签名算法等。
对于ERC4337的实现，vitalik给出了一个路线图，其中包括：
短期：
让ERC-4337投产，支持将EOA升级为智能合约账户
支持ERC4337账户的易用的浏览器插件钱包
实施对Layer2友好的功能，短期在Layer2中推广ERC4337应用
中期：
实施Verkle树，降低gas成本
添加可选的EOA到ERC4337的转换
添加crLIst逻辑
长期：
考虑强制实行EOA转换，和单一的ERC4337账户
Web3Auth提供了一种与web2类似的社交认证方法，可以让web3认证保持与web2一致的使用体验。
Web3Auth是一项toB的应用，需要应用程序自主集成和配置后，用户才能体验到相应的认证体验，包括：
主流社交帐户登录和无密认证：用户可通过 Google、Twitter、GitHub 和其他 OAuth 提供商进行注册。用户还可以通过发送电子邮件的方式，进行无密码设置的注册流程。
支持Web3 钱包与密钥管理：可授权用户使用自主选择的钱包或密钥管理。比如用户可以使用他们现有的钱包登录或选择密钥管理（导入助记词），并将其直接连接到应用程序。
web3auth可以为用户提供类似web2的注册和认证体验，只需要通过第三方社交认证即可完成。
同时，web3auth还支持非托管的公钥基础设施（SSS 2/3 Shamir's Secret Sharing），这种方式极大方便了不懂管理密钥的用户，同时做到既是非托管钱包（用户完全自主掌握资产），又无需用户自行保管密钥。
如果觉得这种非托管方式不够安全，用户也可选择采用自己常用的钱包进行链接登录，比如ledger、phantom等。浏览器插件钱包keplr就是用web3auth扩展，用户可自行体验。
UniPass是多链统一加密身份应用，提供基于电子邮件的非托管社交恢复钱包解决方案。可以通过无密钥的方式控制用户的加密身份。还可以通过加密方式验证多链地址甚至社交帐户。
在前端功能上，unipass与web3auth类似，都有提供社交认证、社交恢复钱包等功能。相对已实现功能，unipass的2022年产品规划中提到的能力，与本文锁期望的去中心化身份演进有很多契合之处，其中包括：
web3身份聚合：基于密码学实现多链多账户的聚合。通过这种聚合方式，可以将用户在不同链上不同地址的行为聚合到一个身份ID中，实现信任的传递。简单说就是可以最大程度提升用户的链上行为评分。
web2身份验证：在智能合约中提供验证电子邮件地址、Twitter 账户、Discord 账户的能力，从而在 Web3 中原生提供 Web2 身份信息。
单点登录与访问门户：通过使用unipass id，进行多应用的统一登录。并为用户提供统一的web3门户导航。
身份标识对于身份识别非常重要，web3中每个账户都是一长串类似乱码的字母+数字，这难于记忆和识别。
ENS是一个基于以太坊区块链的分布式、开放和可扩展的命名系统。其推出的xxx.eth服务，将可读名称映射到了0x123xxx...的标识符，这在一定程度上缓解了这种识别困难。
Nametag 的目标是成为建立在区块链上的通用命名服务，用户通过铸造、存储、交易和使用唯一命名的 NFT 作为他们的通用用户名。
Lens 是Polygon上的 Web3 社交图谱协议。它的目标是形成一个完全可组合的、用户拥有的社交图谱。该协议从一开始就采用模块化设计，允许第三方基于协议开发新功能，同时确保用户拥有的内容和社交关系不可变。
其中ENS和Nametag是想成为基础命名服务让其他应用都来引用和适配。而Lens是想做社交基础设施，自带的xxx.lens有点类似微信名。最终哪种方式会在web3中更受欢迎，还有待时间验证。
对于web3用户来说，相对web2有一个更为重要的需求是自主的安全性，一切身份应该是建立在自主可控的安全基础之上。
相对于一个简单助记词导入的metamask热钱包，硬件钱包会更安全。避免了助记词被黑、钓鱼等风险。
在硬件钱包之上，还有更安全的多重签名解决方案，主要面向组织/社区/大额资金的管理需求。
对于一般个人，硬件钱包就已经相对比较安全了。但对于组织而言，还要考虑单点风险、作恶风险、授权风险等等，因此采用多签会更符合大额资金安全管理的需要。
Gnosis Safe 是一个可在多链运行的智能合约钱包，需要最少人数批准交易才能执行（M-of-N）。
Safe是一个智能合约账户，提供的能力包括：多签、限制转账金额、白名单转账、捆绑交易、紧急冻结/恢复账户、预设条件触发操作等。
上文的大量铺垫，是为了能更好的提出一种架构。它能更好的帮助用户进入web3应用，同时能获得更大的安全性和更好的体验感。
在web3里，钱包、账户、身份的概念有些模糊，没有清晰区分，往往钱包就是账户，账户被当做身份。
实际身份是一个集合，而账户是我们使用应用的具象载体，是身份的外延。而加密钱包是我们账户的一种载体和验证方法。
去中心化身份可以被分为三个层次，分别是：外显身份、代理身份和主权身份。
代理身份是一系列专属功能的账户，比如社交账户、游戏账户、交易账户、DeFi账户、匿名账户等等。
在这个模型中，所有的代理账户都可以是主权账户控制的合约账户，在发生危险时可以使用主权账户重置密钥，避免资产损失。同时可以延续各种行为画像。
这些代理账户是用户不同身份角色的代理，他们之前拥有独立用途和安全边界。避免使用一个账户什么都做，在安全的基础上又能提供便捷的体验。
比如社交账户中没有资产，专门用于登录各种应用，转评赞。游戏账户专门用于玩链上游戏，跟NFT账户可以共用或是分离。而NFT账户有可以专做一个貔貅账户，只买不卖，避免被黑。当要卖时再临时授权挂单。
为什么要采用这种按照角色分离的账户设置？
实际我们在使用web2应用时，大多时候也都是每个应用使用了不同的账户，他们之间没有统一的联系，账户名一样也是我们的主观选择。
而社交登录流行后，我们大多采用微信、gmail等认证方式，这种实际也是授权在应用中建立了一个新的账户映射，而不是直接使用gmail等作为账户主体。
在这个模式下，微信和gmail更类似我们的主权身份，他们可以恢复我们在不同应用中被忘记的账户，或是重置这些账户的密码。
角色分离的好处，是可以将风险隔离，可以提升使用不同应用的体验。我们不需要每次关注人时，都打开硬件钱包授权。而在需要操作资产时，又可以进行更复杂的策略授权，避免不小心或恶意的被盗。
使用代理账账户，我们会担心代理账户产生的行为无法共享，会降低我们在一些场景下的评级。这个问题实际可以通过外显身份的设置来解决。
外显身份是一系列凭证、标识、行为、关系、声誉的集合。
我们可以简单的理解外显身份就是一个个身份标签，主要作用是方便外部关系对我们的身份进行标识。
比如ens、lens等就是一个标识的外显身份，他们的作用是在社交关系上让身份更加易读。
poap是一类行为轨迹的外显身份，它主要是标记我们参与了哪些活动，类似的还有galaxy、rabbithole等。
在vitalik的SBT论文中，提到灵魂绑定token的很多用处，实际都是这种外显身份的能力范围。比如我们的社交关系、信誉、学历证书等等，都可以采用SBT的方式，与我们的身份进行绑定。
在实际应用层面，外显身份实际可以与代理身份合一，他们可以就是同一个账户地址，只是在逻辑层面加以区别会更好的为用户提供服务，或是便于应用进行设计和体验提升。
比如有些用户更加注重安全和隐私，那么这种外显身份就可以是独立的账户，专门用户外部的展示和关系构建。
而代理身份的行为映射完全可以通过隐私计算完成，既可以让我们的身份更像一个整体，又可以让用户可以灵活的控制向外部展现哪些身份特征。更进一步，我们可以灵活的构建多个外显身份，可以有更真实的，也可以有更匿名的。这样会降低用户使用的心里门槛。
在技术层面，要实现这种设计，目前的做法可以采用链上代理的模式，类似在链上签署一个授权，记录代理身份和外显身份的授权关系。一旦外显身份有什么问题，可以重新签署授权去更新或禁用身份行为的授权。听橙皮书关于DID那期播客，有讲到unipass就是采用了这种链上授权模式。
另一种更隐私的方式，可以采用合约账户+零知识证明的方式，以一种外部无法获取直接关系，而可以证明用户的身份不是伪造的方法，来实现这种身份属性的关联和外显。
采用这种外显身份与代理身份分离的设计方式，直观好处就是让用户的微信账号与银行账号分离。而不是别人知道你的微信号，就可以直接看你银行资产，甚至可以看你的钱从哪赚的，怎么亏的。
Not Your Keys, Not Your Coins.
这是web3最重要的基础，是个人资产神圣不可侵犯的保障。
对密钥的安全管理，一直是参与加密游戏的最重要一课，很多人因为保管不善而损失资产。
而如何安全的保管密钥，相对来说也是一件比较专业的事，新用户很难短时间掌握，需要大量的实践和很多次突破心理防线，才能真正自己安全的用非托管钱包管理资产。
密钥就是我们的主权身份，它宣誓了一切都是自己可控的。而不像web2那样说被禁用就被禁用。
而密钥的安全管理，一定是采用去中心化非托管的方式。这让我们能随时对自己的账户有控制权。
如果是个人使用，到硬件钱包这一层已经相对比较安全。如果是一个组织/社区来使用，可以采用多签的方式。
在未来架构中，这一身份可以是我们最不常使用的身份。只需要在创建代理身份时，用它来授权即可。当代理身份存在风险时，我们可以用它来充值代理身份的密钥，确保一切资产都在自己最终的可控范围。
对于web3新人，这种主权身份实际也可以采用第三方服务来实现。这是一种基于去中心化非托管的方案，比如像web3auth的SSS方案。这也降低了新人使用密钥的门槛。
以上提到的三个身份层次，他们实际上可以是辩证统一的整体，极端情况他们就是一个地址而已，所有身份都汇聚到一个公钥地址，目前很多用户也是在这么使用。
但这样的应用方式不够安全，很多人因此丢失了资产。由于很多心理阻碍，也无法真正让各类账号很好的组合起来，让一些本是积极建设的用户，在链上评分上不会很好。
目前的身份账户体系，并没有像web2那种更好的服务于用户。在web3，最重要的就是资产所有权问题，而用户与链上资产的关系，就是通过身份来桥接的。
只有处理好身份的关系，才能更好的让用户使用链上资产，使用各种web3应用。
通过将去中心化身份进行分层设计，一方面可以让专业人做专业事，各项目如果能围绕一个大的共识方向去做，也能更快更好的实现高度可组合的身份产品矩阵，真实的让用户得到实惠。
另一方面，也是为了能让用户更好的理解web3的身份账户概念，在先进来的前提下，通过更多的使用来慢慢了解和熟悉身份的安全管理。
因为web3的身份是属于个人的，因此需要我们自己对自己的身份资产负责。
最终，我们其实拥有的是一个身份集合（钱包账户集合）。
在上面的举例中，看似有很多身份概念很复杂。但实际如果有这样的应用，它可以将这些元素汇聚在一个应用中，让用户实际没有这些复杂概念的感知，只是去用就好了。
要达到这个理想化的架构，我们要做哪些事：
专业化web3身份认证服务商
toB先行，各DAPP采用web3身份认证组件
标准化认证服务、接口和流程
易用化用户注册、认证流程
提供代理账户能力，实现账户间的身份授权（链上）
支持浏览器插件的合约钱包
支持直接在web3的移动应用采用社交化认证
大量web3应用对合约账户的支持和安全的密钥管理
面向个人用户的一站式综合服务
ERC4337的实施，实现账户抽象
安全多签和硬件钱包的普及
去中心化非托管的密钥基础设施
对于个人用户，我们可以做些什么：
基于现有条件，划分自己的账户角色
使用不同角色的账户参与不同类型应用，风险隔离
安全保管好助记词/私钥，学习相关知识
尝试使用新型web3认证基础应用
对于专业身份认证、DID、社交等应用可以做些什么：
提供更安全的合约账户功能
尝试提供代付注册、交易费等能力
尝试向web2渗透认证能力，甚至是替代
No activity yet