Neo联合创始人Erik Zhang最终敲定了NEP-20标准，这是一项创新的身份验证标准，允许用户使用自己的Neo钱包登录网站、游戏和应用程序。该标准定义了基于地址的身份验证挑战/响应协议，旨在消除对用户名、密码和单独账户注册的需求。在首次提出数年之后，该标准现已达到Neo增强提案库中的“Accepted”状态。
平台控制身份的问题
在大多数互联网应用中，身份依赖于平台。用户创建由服务管理的账户，凭据存储在服务的服务器上，用户对自己身份数据的控制是间接的。这带来了两个反复出现的问题：中心化安全风险（单一漏洞可暴露整个用户群）以及依赖第三方登录提供商的脆弱性——其API、政策和可用性可能会在没有预警的情况下改变。像“使用Google登录”这样的服务旨在简化注册，但应用程序通常要求用户额外绑定手机号或邮箱，因为没有产品能完全信任不受其控制的外部身份解决方案。
NEP-20的工作原理
NEP-20将身份验证从平台验证转变为用户证明。用户不是通过中心化服务确认身份，而是直接通过加密签名证明自己对Neo地址的所有权。流程遵循挑战/响应交互：首先，应用服务器生成一个Challenge负载，包含服务器域名、一次性随机数、时间戳、支持的签名算法和Neo网络标识符。接着，用户钱包展示关键信息供确认，用户批准后钱包签名Challenge数据并返回Response负载，包含公钥、地址、随机数、时间戳和签名。最后，应用验证签名与返回的公钥和地址是否匹配，检查域名、随机数和时间戳的有效性。此过程中不传输密码，不在服务器上存储凭据，也不进行链上交易。
安全设计
NEP-20包含多项约束以防止常见攻击：域绑定要求Challenge包含服务器域名，钱包必须验证并显示给用户；随机数过期确保每个请求使用唯一的限时随机数，服务器需防止重放；时间戳验证让双方检测过期或重放请求；签名验证确保签名与公钥匹配；用户明确同意要求钱包展示关键信息并获得用户确认。当前支持的签名算法为ECDSA-P256，但标准允许未来扩展。
三种交互模式
NEP-20定义了三种用户与应用的交互场景：二维码模式：网站显示编码Challenge的二维码，用户用移动钱包扫描并确认登录，钱包将签名Response发送至回调URL，实现跨设备认证；插件模式：浏览器扩展钱包检测网站是否支持NEP-20，网站前端从服务器请求Challenge，传递给钱包的authenticate方法，钱包验证域名并提示用户，返回签名Response，实现无缝登录；连接模式：通过持久连接工作，游戏客户端或命令行工具连接服务器，接收Challenge，签名并返回Response，适用于原生应用、后端服务和CLI工具。
设计决策与未来扩展
NEP-20的一个关键设计是完全脱链运行。标准仅支持标准单密钥Neo账户（System.Crypto.CheckSig），这代表绝大多数Neo地址。在评审过程中，Neo SPCC建议支持多签和脚本账户，但Zhang回应称，这样做将要求启用NEP-20的应用运行Neo节点或信任的RPC服务器，这对传统应用或游戏平台目前不可接受，因此需要完全脱链的认证方案。标准的grant_type字段当前设为“Signature”，但设计为可扩展，为未来支持脚本验证留了空间。
应用场景与市场影响
NEP-20旨在作为跨不同环境的通用认证层：Web应用可提供钱包登录替代传统凭据；游戏无需单独账户系统即可验证玩家；后端服务和CLI工具可直接集成钱包签名。标准中的网络字段使用Neo的ProtocolSettings魔法数字，使应用能在单一实现中支持多网络认证。这一标准的最终敲定，标志着Neo生态在Web3身份认证领域迈出关键一步，可能吸引开发者和用户从传统中心化登录迁移，推动去中心化身份解决方案的普及。与以太坊的“使用以太坊登录”类似，NEP-20为Neo网络增添了重要的基础设施，有望提升Neo在公链竞争中的差异化优势。随着越来越多应用集成钱包登录，用户隐私和安全将得到显著提升，同时降低服务器端的存储成本和风险。Erik Zhang的公布消息显示，该标准已在社区经过数年迭代，最终达成共识，为Neo生态的未来发展奠定了坚实基础。