您正在查看: Solana-优秀转载分类下的文章

Solana + 以太坊：罗马协议链接

2024-12-17　 Surou　阅读　 Solana-优秀转载　 0 评论

介绍

罗马帝国再次重生，但这一次是数字化的。

让我们回到 1500 年前，想象一下古罗马，那里有繁华的市场、角斗士游戏和战车比赛。但有一个问题，他们征服的地区有自己独特的规则、货币、语言和习俗，这可能会使治理和贸易变得复杂。

为了解决这个问题，他们开始努力修建道路、渡槽和桥梁，连接整个帝国，使贸易、旅行和日常生活比以往任何时候都更加顺畅。众所周知，罗马帝国是当时最伟大的帝国之一。

快进到今天的区块链世界，我们几乎回到了早期的罗马时代，当时的网络孤岛彼此之间难以轻松通信。罗马协议正是为此而生，它希望重现古代连接天才——但这次是在区块链上。就像古罗马修建道路和桥梁一样，罗马协议也在 Solana 和以太坊生态系统之间建立通道，以便 dApp 和资产可以在它们之间自由流动。这还是同一个罗马，但罗马袍子更少，科技更多！

什么是罗马协议

Rome 协议是一种解决方案，它允许开发人员和用户在 Solana 区块链上运行基于以太坊的应用程序 (dApp)，从而结合两个平台的优势。Rome 通过在Solana和其他基于以太坊的网络之间建立顺畅的链接，提供跨不同区块链进行快速、安全交易的工具。

通过 Rome EVM、共享序列器、Interop 和 DA（数据可用性）等组件，它允许开发人员构建可以在不同区块链环境中无缝运行的应用程序。

本质上，Rome 旨在将以太坊的生态系统带入 Solana，使用户无需离开一个平台即可与两个区块链上的应用程序进行交互。它支持跨链交易、公平的交易排序和高速数据处理，使去中心化应用程序更加灵活、高效和用户友好。

Rome 协议就像一座桥梁，让为以太坊构建的应用程序可以在 Solana 区块链上运行，让用户同时享受两全其美的优势。例如，如果您想在以太坊上构建 dApp，比如去中心化交易所 (DEX)或借贷平台，并希望将其扩展到 Solana 更快、更低成本的环境。借助 Rome，您可以将以太坊 dApp 带到 Solana，而无需从头开始重建它。

罗马协议架构：关键组件

罗马有几个部分可以实现这一目标：

Rome EVM：可以将其视为 Solana 上的以太坊引擎。就像以太坊应用程序可以轻松在其他兼容以太坊的区块链上使用一样，开发人员现在可以直接在 Solana 上部署他们的以太坊应用程序，并且交易方式让以太坊用户感到很熟悉。
共享序列器：此工具可确保公平高效地组织来自不同 rollup（或网络）的交易，以便按正确的顺序处理每笔交易。例如，如果用户在区块链之间交换代币，则共享序列器可确保交换的双方同步进行。
Rome Interop：假设您正在使用 Solana 的 DeFi 服务，但同时又想与以太坊上的资产进行交互。借助 Interop，用户可以无缝链接跨区块链交易 — — 例如在 Solana 上借款，同时在以太坊上保护资产。
Rome DA（数据可用性）：此功能可确保数据在 Solana、Celestia或 Ethereum 上可访问且安全，具体取决于配置。如果您正在运行包含关键交易数据的应用程序，Rome DA 可确保这些数据安全地记录在一条或多条链上。

简而言之，罗马协议允许开发人员将以太坊的生态系统带入 Solana 的速度和可负担性，让用户享受跨不同区块链的顺畅交互，例如贷款、交易或质押，所有这些都在一次连接的体验中。

Rome Stack，来源；Rome Docs

罗马议定书使命

罗马协议的使命是让区块链网络更具互操作性和模块化，解决当今区块链可扩展性和用户体验的一些关键障碍。
其目标是创建一个无缝、有凝聚力的生态系统，其中数据、资产和功能可以轻松地在不同的区块链之间移动，利用 Solana 和以太坊的独特优势。
罗马协议如何增强区块链之间的互操作性和模块化：

互操作性：桥接区块链网络

罗马协议实现了互操作性，允许资产和数据在不同区块链之间轻松转移。通过连接 Solana 和以太坊，它克服了孤立生态系统的限制，让每个链上的应用程序可以相互交互。

这种互操作性使跨链应用程序（例如去中心化金融（DeFi）平台）能够无障碍运行，从而增强了用户体验和流动性。

想象一下，如果一个国家的每个城市都有自己独特的货币和交通系统，人们出行或做生意会变得很困难。罗马议定书充当了国家系统，使货币和城市间交通标准化，使流动和交易变得无缝衔接。

通过强大的基础设施连接 Solana 和以太坊，Rome 旨在实现原子可组合性，即通过单一原子操作（全部或全部）跨区块链进行交易的能力。

资料来源：罗马文件

这种互操作性使一条链上的去中心化应用程序 (dApp) 能够与另一条链上的资产、数据或逻辑顺利交互，从而消除孤立生态系统造成的障碍。让我们来看看如何实现；

Rome EVM：通过将以太坊的 EVM 环境引入 Solana，Rome 使开发人员能够轻松地在 Solana 上部署以太坊 dApp，而不会损害 dApp 的功能。这使用户更容易执行跨链交易，而无需进行大量的技术变通。
Rome Interop (SDK)：此工具包支持跨链和跨 rollup 交易，允许开发人员创建使用跨多链数据和流动性的应用程序。这种连接为 DeFi、GameFi 和其他区块链领域创造了更丰富的环境，因为资产和应用程序可以无缝跨越生态系统。

Rome 交易：促进原子可组合性

Rome 支持各种类型的交易，每种交易都针对跨链的特定交互而量身定制：

Rhea 交易：Rhea 交易将单个 rollup 交易封装在 Solana 交易中，这意味着交易直接在 Solana 的基础设施上执行。此设置非常适合简单的单 rollup 交易，这些交易不需要与其他 rollup 或链交互。

资料来源：罗马文件
Remus 交易：Remus 将多个跨 rollup 交易捆绑为单个 Solana 交易。这意味着所有 rollup 交易要么一起执行，要么一起失败，从而实现原子性。此设置对于涉及多个 rollup 的操作特别有用，例如跨 rollup DeFi 操作或捆绑支付。

资料来源：罗马文件
Romulus 交易：Romulus 允许在单个跨链交易中执行 rollup 和 Solana 原生交易的组合。此功能非常适合需要同时在 Solana 和以太坊 rollup 上进行操作的场景，例如跨链转移资产或执行涉及不同区块链生态系统的复杂 DeFi 策略。

资料来源：罗马文件

该系统确保原子性，即交易的所有部分要么全部成功完成，要么全部失败。例如，跨 Solana 和以太坊的套利交易只有在所有子交易都成功的情况下才会完成。

罗马协议互操作性的影响

增强的 DeFi 功能：借助 Rome Protocol 的原子可组合性，开发人员可以构建更先进的 DeFi 产品，例如多链闪电贷、跨链收益农业和利用 Solana 速度和以太坊流动性的套利工具。
提高用户灵活性和效率：用户可以自由访问多个生态系统中的功能，而无需手动切换网络或担心任何一方的交易失败。这种无缝性鼓励了 dApp 的更广泛采用和可用性。
开发灵活性：Rome 允许开发人员构建利用以太坊和 Solana 最佳功能的应用程序，而无需重写整个应用程序。这扩大了创新的可能性，同时降低了多链应用程序的技术和财务障碍。

模块化：构建专业化、可扩展的层

Rome Protocol 采用模块化区块链架构，将传统区块链组件拆分为专门的层。与所有功能（计算、共识和数据存储）都发生在一条链上的单片区块链不同，Rome 将这些层解耦。

这种方法使每个组件能够独立运行但又与其他组件同步，从而提高了灵活性和可扩展性。

可以将模块化区块链想象成一家拥有专门部门的公司，例如 IT、财务和客户支持。每个部门都独立运作，但为了公司的成功，他们无缝协作。同样，Rome 的模块化架构允许每一层都专业化并高效运行。

Rome Protocol 的架构是模块化的，旨在将区块链功能分解为不同的组件（例如计算、数据可用性和交易排序），从而使每一层都专注于其专门的功能。让我们来看看；

共享排序器 (Rhea)和Hercules：这些组件分别处理交易排序和状态推进，从而实现可扩展的独立处理。这种模块化方法不是在单个区块链层中处理所有内容，而是将任务分开，从而提高了速度和灵活性。

资料来源：罗马文件
数据可用性：Rome Protocol 利用 Solana 的高吞吐量和 Celestia 实现数据可用性，这意味着开发人员和应用程序可以选择最合适的数据存储和检索方法。这种模块化选项允许汇总独立配置其数据需求，同时受益于 Solana 的安全性和速度。

资料来源：罗马文件

模块化区块链架构的重要性：通过 Rome 的模块化增强 Solana

模块化区块链架构是一种变革性方法，它将区块链功能划分为单独的专用层，每个层都专注于一个核心功能——例如数据可用性、共识、结算或执行。

这种模块化设置使每一层都可以独立优化，从而实现灵活性、可扩展性和跨链互操作性。Rome 对 Solana 的模块化利用了这些原则，创建了一个以 Solana 的速度和成本效益为基础的生态系统，同时扩展了与以太坊的功能和互操作性。

Rome 的模块化设计如何增强更广泛的区块链生态系统：

在 Solana 上启用 EVM 兼容性

扩大开发者生态系统：Rome 的模块化方法在 Solana 上引入了与以太坊兼容的虚拟机 (Rome EVM)，允许开发者无需修改即可部署基于以太坊的 dApp。这使 Solana 向庞大的以太坊开发社区开放，鼓励流行的以太坊应用程序迁移并吸引新项目。
与以太坊 dApp 的互操作性：通过将OP Geth（以太坊的执行客户端）集成到 Solana 生态系统中，Rome 使以前仅限于以太坊的 dApp 能够在 Solana 更快、更实惠的网络上运行。例如，以太坊上的 DeFi 项目可以扩展到 Solana，为用户提供更多选择，同时受益于 Solana 的低成本交易。

资料来源：罗马文件

解耦数据可用性和结算

可配置数据可用性 (DA)：Rome 的架构支持多种 DA 解决方案，允许rollup选择使用 Solana、Celestia 或以太坊来实现数据可用性。通过使 DA 模块化，Rome 让开发人员能够根据自己的特定需求灵活地优先考虑成本或安全性。例如，专注于高吞吐量的 rollup 可能会选择 Solana 来实现 DA，而需要更高安全性的 rollup 可能会选择以太坊。
以太坊上的高效结算：Rome 通过使用 Hercules 将 rollup 状态提交到以太坊，将结算与交易执行分离开来。结算中的这种模块化使 rollup 能够从以太坊的安全性中受益，而不会牺牲 Solana 的速度，从而使系统既高效又安全。

资料来源：罗马文件

跨链和跨 Rollup 可组合性

增强的多链 dApp 功能： Rome 的模块化方法支持 Remus（跨 rollup）和 Romulus（跨链）交易，允许应用程序跨不同的区块链执行原子操作。这对于需要 Solana 和以太坊之间可组合性的 dApp 至关重要。例如，DeFi 协议可以提供跨两个网络的流动性池，使用户无需切换链即可汇集和交易资产。

资料来源：罗马文件
集成多链生态系统：通过确保原子性和可组合性，Rome 增强了区块链应用程序的互联互通性，使各种 dApp 和资产能够无缝交互。这为在多条链上同时运行的新型去中心化应用程序铺平了道路，增强了用户体验并拓宽了区块链现实世界应用的范围。

资料来源：罗马文件

加速开发并降低复杂性：

简化的开发人员体验：Rome SDK 是模块化设置的一部分，它为开发人员提供了一个易于使用的框架来构建跨链和跨汇总应用程序。借助编写原子交易、将其提交给 Solana 并订阅汇总内存池的工具，开发人员可以更快、更轻松地构建多链应用程序。
提高网络效率：通过模块化执行、排序、DA 和结算，Rome 优化了网络资源，确保每个功能都由最合适的组件处理。这提高了 Solana 的吞吐量并最大限度地降低了交易费用，使网络更加高效，可供更广泛的用户和用例使用。

构建可扩展且面向未来的区块链生态系统

通过专业化实现可扩展性：使用 Rome 对 Solana 架构进行模块化有助于提高可扩展性，因为这样可以让每个组件专注于其特定功能。随着区块链使用的增长，模块化可确保每个层（无论是数据可用性、排序还是结算）都可以独立优化和扩展，而不会破坏整个系统。
灵活应对未来： Rome 的模块化设计使其能够适应区块链技术的未来升级或变化。例如，如果出现新的数据可用性解决方案，Rome 生态系统中的汇总可以将其集成，而无需更改其他组件。这种灵活性确保 Rome 和 Solana 能够随着技术进步而不断发展。

为什么互操作性和模块化很重要

互操作性意味着区块链协同工作，而模块化意味着区块链内功能的分离，这是未来区块链应用的基础。像以太坊这样的传统区块链由于需要在一条链上处理每笔交易和数据请求，因此往往难以实现可扩展性。罗马协议带来了模块化设计和可互操作的解决方案，允许由专门的系统管理单独的功能，例如用于交易处理的 Solana 和用于结算的以太坊。通过这样做，罗马协议可以优化性能并减少瓶颈。

罗马协议如何解决区块链中的关键挑战

罗马协议解决了区块链生态系统中的几个关键问题：

跨链互操作性：Rome 为跨以太坊和 Solana 的顺畅、安全交易提供了一个框架，解决了传统桥梁的低效率问题。
原子可组合性：通过确保跨链操作的原子性，Rome 支持闪电贷和套利等关键的 DeFi 功能，其中跨链交易成功至关重要。
跨汇总交易的可扩展性：Rome 的共享序列器优化了汇总的交易排序和数据可用性，从而提高了多链 dApp 的性能。
数据可用性和结算：Rome 的模块化方法可确保跨网络的高效数据可用性和最终结算，使用 Solana 确保速度，使用 Ethereum 确保安全性。
简化的开发人员体验：Rome SDK 为开发人员提供了全面的工具包，简化了构建跨链应用程序的过程并加速了采用。

用例：罗马协议的实际应用和影响

罗马协议允许与以太坊兼容的应用程序在 Solana 上运行并支持无缝跨链交易，从而实现跨区块链垂直领域的广泛用例。以下是罗马协议的功能将对现实世界产生影响的一些关键垂直领域：

DeFi（去中心化金融）

跨链闪电贷：闪电贷已成为 DeFi 用户必不可少的工具，允许在单笔交易中借入和还款，通常用于套利或流动性提供。借助 Rome 的跨链原子性（Remus 和 Romulus 交易），用户可以在 Solana 上进行闪电贷，并在一笔有凝聚力的交易中跨以太坊和基于 Solana 的交易所进行套利。
跨链质押：Rome 允许用户在基于以太坊的平台上质押资产，同时在 Solana 上执行收益耕作策略。这种灵活性使用户可以从 Solana 的 DeFi 协议中获得更高的回报，同时将资产质押以获得以太坊上的奖励。
同步 DEX 操作：Rome 允许去中心化交易所 (DEX) 为用户提供即时跨链交易。例如，用户可以在基于以太坊的 DEX 上交易资产，并在 Solana 上交换，而无需任何手动桥接或复杂的交易步骤

NFT 和游戏

跨链 NFT 铸造和市场：借助 Rome，可以在 Solana 上创建 NFT，并立即在以太坊市场上提供（反之亦然）。Rome 的互操作性和原子可组合性确保当在一条链上铸造 NFT 时，它会自动反映在另一条链上，从而使 NFT 真正成为多链。
跨区块链的游戏内资产转移：对于基于区块链的游戏，游戏内物品或货币很有价值，Rome 允许开发人员创建可在 Solana 和以太坊之间无缝交互的游戏内资产。玩家可以在基于以太坊的游戏中购买物品，并在基于 Solana 的游戏中使用它们，而无需手动转移或增加成本。
多链忠诚度计划：Rome 支持忠诚度计划，奖励和收藏品可以在生态系统之间流动。这对于寻求增加跨平台用户参与度的品牌或项目来说非常有价值，因为它们可以创建无缝、可互操作的奖励系统。

现实世界资产（RWA）和代币化资产

跨链代币化资产：Rome 的原子交易可确保无需信任、无需托管的跨链交易，非常适合代币化的现实世界资产，如房地产、股票或商品。例如，用户可以在以太坊上将房地产代币化，并在基于 Solana 的 DeFi 平台上利用它，而无需复杂的托管中介。
资产转移的跨链结算：罗马协议允许跨链即时、可验证地结算代币化资产。金融机构或市场可以使用该功能来处理跨多链证券，从而通过一个无缝步骤提供流动性和交易终结性。
合规资产管理：通过 Rome DA 提供的数据可用性和透明度，机构参与者可以更好地确保跨多个链的监管合规性，同时在 Solana 上获得高吞吐量和更低成本。

DAO（去中心化自治组织）

跨链治理：当 DAO 的成员分散在多个区块链上时， DAO通常会面临挑战。Rome 支持跨以太坊和 Solana 互操作的治理系统，允许成员投票或参与 DAO 活动，无论他们使用的是哪条链。
多链资金管理：Rome 可以帮助 DAO 管理以太坊和 Solana 上的资金，在统一的原子交易中执行交换、分配或收益生成等交易。这对于希望在不手动桥接资产的情况下最大限度提高资金效率的 DAO 尤其有价值。
同步提案和投票：通过确保跨链数据可用性，Rome 可以促进同步投票，其中每个成员在以太坊或 Solana 上的投票都会被同时记录和识别，从而创建跨链的有凝聚力的治理体验。

跨链套利与做市

跨链套利机器人：借助 Rome Protocol，做市商和套利者可以运行在以太坊和 Solana 之间执行原子交易的机器人。例如，套利机器人可以发现以太坊和 Solana 上的 DEX 之间的价格差异，在一条链上执行交换，并立即在另一条链上转售。
跨链自动做市：Rome 可以促进横跨以太坊和 Solana 的流动性池，从而实现跨链流动性提供和提取。这使用户能够访问多链流动性池和更好的交易选项，而无需手动来回移动资产

多链 dApp 开发

跨链一站式 dApp 部署：Rome 的架构，尤其是 Rome EVM，让开发者能够轻松地在 Solana 上直接部署以太坊 dApp。以太坊开发者可以快速将现有的 dApp 扩展到 Solana，从而吸引来自两个生态系统的用户，而无需额外的开发开销。
统一的跨链钱包和投资组合：Rome 可用于构建钱包，无缝显示和管理以太坊和 Solana 的资产。用户可以查看他们的 Solana NFT 和以太坊代币，并进行交易，而无需在平台之间切换。
原子跨链智能合约：Rome 允许开发人员编写智能合约，只需一步即可在以太坊和 Solana 上执行功能。例如，借贷 dApp 可以允许用户在 Solana 上存入抵押品，同时在以太坊上借贷，所有这些都通过一次智能合约调用完成。

结论

Rome Protocol 通过将 Solana 的速度与以太坊的生态系统相结合，代表着向互联、去中心化未来的转变。凭借其模块化架构和对互操作性的关注，Rome 解决了当今区块链面临的关键挑战，为下一代区块链应用创建了一个强大、适应性强且用户友好的环境。

罗马协议不仅仅是一个技术解决方案，也是迈向更加集成、高效的区块链生态系统的基础性一步——在这个生态系统中，交易、数据和应用程序可以轻松地跨链流动。

参考文献和资源

罗马议定书官方文件
罗马议定书网站
罗马议定书官方X帐号
罗马协议 Discord 服务器
Solana 开发者资源
以太坊开发者资源
EVM 兼容区块链
L2 区块链上的排序器终极指南
[模块化和单片区块链](https://celestia.org/learn/basics-of-modular-blockchains/modular-and-monolithic-blockchains/#:~:text=Modular blockchains,-The framework behind&text=A design is modular if,of trying to do everything.)
什么是区块链互操作性
什么是 Roll Up
DeFi 中的可组合性是什么
区块链中的原子性是什么？为什么它很重要？

原文：https://medium.com/@tempestgirl1/solana-ethereum-the-rome-protocol-bridge-4498227dbafa

推出 Solana 签名 SDK：让 Solana 用户能够访问 EVM dApp

2024-12-17　 Surou　阅读　 Solana-优秀转载　 0 评论

Solana Signature SDK 是一个以开发人员为中心的工具包，旨在将 Solana 钱包（例如 Phantom、Backpack 和 Solflare）集成到通过 Neon EVM 部署在 Solana 上的与以太坊兼容的 dApp 中。

关键要点

统一的用户体验：使用与 Solana 兼容的钱包以及与以太坊兼容的 dApp 进行交易签名。
技术创新：通过链上签名验证支持以太坊交易的 Solana 原生 ed25519 签名。
简化开发：通过 SDK 快速集成钱包和交易管理，几分钟内即可完成设置和功能。
生命周期透明度：从钱包到 Neon EVM 上执行的交易流程的详细概述。
高级功能：支持 Solana 程序调用、ERC20-SPL 资产管理和交易调度。

随着 Solana 签名钱包 SDK 的发布，我们朝着实现 Solana 原生集成和简化 Solana 环境中与以太坊兼容 dApp 的用户交互迈出了重要的变革一步，正如我们的白皮书中所强调的那样。

Neon EVM 和钱包集成简介

Solana 签名钱包 SDK 工具包使开发人员能够构建 dApp，使 Solana 用户能够与部署在 Neon EVM 上的智能合约进行交互。与以太坊兼容的 dApp 历来依赖类似以太坊的签名 (secp256k1) 进行交易身份验证。这种依赖关系为 Solana 用户带来了障碍，要求他们使用 MetaMask 等其他工具并进行复杂的流动性转移。Solana 签名钱包 SDK 与 Neon Proxy 一起解决了这个问题。通过匹配 Solana 的 ed25519 签名方案和以太坊的交易要求，此 SDK 简化了钱包集成和跨生态系统的资产可访问性。

从本质上讲，此 SDK 简化了交易管理，如下所示：

在 Solana 钱包内创建 EVM 交易。
通过 Neon EVM 的链上内存池打包并提交交易
通过 Neon Proxy 执行和状态管理
Neon 和 Solana 的状态更新。

通过抽象交易转换的复杂性并增强两个网络之间的兼容性，它允许开发人员专注于构建和与去中心化应用程序（dApps）交互，而不必担心底层基础设施障碍。

让我们深入了解细节、技术概述、代币管理流程、优势、局限性和未来前景。

Solana 签名钱包 SDK 详细概述

Neon EVM Solana 签名钱包 SDK 是一种模块化且灵活的解决方案，旨在使开发人员和用户受益。

好处：

对于用户

简化的体验：使用现有的 Solana 钱包与与以太坊兼容的 dApp 进行交互。
降低复杂性：无需额外的钱包或复杂的流动性转移。

对于开发人员

快速集成：通过全面的 SDK 工具简化钱包连接和交易工作流程。
生态系统兼容性：构建适合 Solana 和以太坊用户的 dApp，无需额外的开发开销。

Solana 签名验证：功能

Neon EVM Solana 签名钱包 SDK 的一个突出功能是它能够使用 Solana 的 ed25519 签名系统验证 Solana 交易。这一增强功能对于确保通过 Solana 钱包（例如 Phantom、Solflare 和 Backpack）发起的交易在 Neon EVM 网络上准确、安全地处理至关重要。

验证过程在 Neon Proxy 中实时进行，它会在 Neon EVM 上执行任何交易之前检查 Solana 签名的真实性。通过原生验证 Solana 的 ed25519 签名，Neon Proxy 无需手动验证签名或使用中间层。这意味着交易可以安全地处理，延迟最少，确保每笔交易都经过身份验证并正确记录。

这种实时验证机制对于 Solana 钱包用户直接与部署在 Neon EVM 上的与以太坊兼容的 dApp 交互至关重要，而无需单独的身份验证方法或 MetaMask 等附加工具。

对于 SDK，为确保流畅的用户体验，两个关键关注领域包括：

通过 Neon Proxy 实现的技术功能；
使用 ERC20ForSPL 管理进行资产管理，用于以太坊和 Solana 网络之间的代币转移。

继续阅读，了解 Neon Proxy 如何支持这一点，以及 ERC20ForSPL 合约如何管理 Solana 和以太坊兼容环境之间的代币余额和转移。

Neon Proxy 变更：增强基础设施功能

Neon Proxy 对于促进交互至关重要。它将类似以太坊的交易打包到 Solana 交易中，消除了实现转换逻辑的负担。代理架构的最新更新引入了新功能，优化了交易处理，并确保与现有系统的兼容性，同时整合了 Solana 签名基础设施。

Solana 签名 SDK 的关键代理增强功能

Solana 签名验证： Neon Proxy 现在可以验证 Solana 的 ed25519 签名，使 Solana 钱包（Phantom、Backpack、Solflare 等）能够直接向 Neon EVM 签名并提交交易。这消除了中间层，简化了流程并确保了安全性。
链上内存池集成：借助链上内存池支持，Solana 钱包交易可以在 Neon EVM 生态系统中透明高效地存储、验证和执行。这一改进增强了可扩展性，并消除了对交易调度链下操作的依赖。

为了实现链上内存池，Neon 引入了NeonTxs 树的概念。这将单个大交易拆分为更小、可管理的单元（NeonTxs），同时保持整体逻辑。

工作原理

交易树：
Neon 合约创建了一个交易“树”，其中较小的单元（分支）可以独立执行。
每个交易都是原子的，这意味着只有交易成功完成，其变化才会生效。
并行执行：
独立交易可以并行运行，从而加快进程。
错误处理：
如果树中的一个交易失败，它不会破坏整个过程。Neon 合约的逻辑可以决定如何处理失败。
最终聚合：
树中的所有交易完成后，它们的结果将被组合（聚合）成最终交易。

使用 Solana 签名 SDK 的代理工作流

交易创建：
Solana 用户通过使用 Solana Signature SDK 通过他们的原生钱包（Phantom、Backpack、Solflare）对交易进行签名来发起交易。
交易通过SDK打包成Neon兼容的格式并发送给Neon Proxy。
链上调度和映射：
Neon Proxy 将用户的 Solana 钱包地址映射到与以太坊兼容的地址，确保与 Neon EVM 上基于以太坊的智能合约正确集成。
该交易在 Neon EVM 内存池中链上调度，等待执行。
交易执行：
Neon Proxy 扫描内存池以查找预定的交易，并使用 Solana 的 ed25519 签名来验证它们。
该交易在 Neon EVM 上执行，触发智能合约交互并更新 Solana 和 Neon 网络上的状态。
执行后清理：
Neon Proxy 通过清理临时资源来确保高效的系统维护，从而优化未来的交易。

虽然 Neon Proxy 可以作为 Solana 钱包和 Neon EVM 生态系统之间交互的推动者，但要充分发挥市场潜力，需要消除资产管理碎片化。跨网络的统一资产管理是推动采用和更集成的用户体验的关键。

ERC20ForSPL 更新：统一代币管理

SDK 的主要功能是其完善的 ERC20ForSPL 合约逻辑，解决了以太坊和 Solana 之间的互操作性挑战。合约通过使 ERC-20 代币能够在 Solana 环境中运行来连接两个网络。重点是完善 ERC20ForSPL 合约逻辑，以统一余额、保持向后兼容性并为开发人员引入强大的工具。具体方法如下：

统一余额管理

PDA 和 ATA 集成：Neon EVM 目前使用程序派生地址 (PDA) 来管理余额。随着关联代币账户 (ATA) 使用的实施，合约将整合这两个关键 Solana 组件，以统一的方式管理余额。
转账优先级：在转账时，合约优先使用PDA余额，如果PDA余额不够，则使用ATA余额。
消除碎片化：这种统一使得代币管理变得更简单、更少碎片化，为用户提供统一的代币管理体验。

这里的传输逻辑很简单：

收件人地址验证：在发送代币之前，合约会检查收件人的地址是否与以太坊（EVM）兼容，并确保他们的 ATA（Solana 版本的钱包）已初始化。
有条件传输：如果 ATA 已准备就绪，令牌将发送到那里。如果没有，则默认将令牌发送到 PDA。
综合余额视图：balanceOf方法现在提供PDA和ATA余额的统一视图，确保准确反映用户的总持有量。

向后兼容性和安全性

虽然 ERC20ForSPL 合约已经更新，但保持向后兼容性（确保现有实现继续不中断地运行）同时添加新功能以增强功能仍然至关重要。
为此，合约通过保留状态变量、方法签名和事件参数来保持与现有实现的兼容性。它在 0xFf000000000000000000000000000000000000000000007 下引入了新的预编译方法，增强了开发人员的能力。isSolanaUser 确定 EVM 地址是否对应于 Solana 帐户，而 solanaAddress 检索与 EVM 地址关联的 Solana 公钥。

构建器预览：使用 SDK 创建的 Neon 交易的生命周期

步骤 1：在前端创建交易

使用 ethers.js、web3.js 或任何其他工具创建 Neon EVM 交易。
使用 Native Wallet SDK 将交易打包成 Solana 交易，通过 Neon Proxy 获取必要的元数据。
（可选）：添加 Solana 资产审批说明，以便 Neon EVM 智能合约直接访问。

步骤 2：Solana 钱包签署并提交交易

dApp 前端将打包的交易发送到用户的 Solana 钱包。
用户通过其钱包 UI 审查并签署交易。
钱包将签名的交易提交给 Solana 网络，并将其安排在 Neon 的链上内存池中。

步骤 3：Neon Proxy 执行预定交易

Neon Proxy 扫描链上内存池并识别准备执行的交易。
在 Neon EVM 上执行交易，从而导致 Neon 和 Solana 上的状态更新。
执行后从内存池中删除交易。

开始使用 SDK

访问存储库：深入研究GitHub上的 Neon Solana Signature SDK 。
开发人员文档：探索全面的文档。
社区开发者支持：加入我们的Discord。查看 Discord 开发频道以获取实时帮助，并寻求我们仅限邀请的 Telegram Builder 聊天访问权限。

原文：https://neonevm.org/blog/unveiling-solana-signature-sdk-enabling-solana-users-to-access-evm-dapps

Solana Hello World（安装和故障排除）

2024-11-26　 Surou　阅读　 Solana-优秀转载　 0 评论

这是 Solana 的 Hello World 教程。我们将引导您完成安装 Solana 的步骤并解决可能出现的问题。
如果您遇到问题，请查看本文末尾的故障排除部分。

安装步骤

安装 Rust

如果您已经安装了 Rust，请跳过此步骤。

# install rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

安装 Yarn

您需要它来运行单元测试。如果您已经安装了 yarn，请跳过此步骤。

# install yarn -- assumes node js is installed
corepack enable # corepack comes with node js

安装 Solana cli

我们强烈建议使用stable版本，而不是latest。 Solana 安装不再支持符号通道名称（edge、beta、stable），因此我们必须指定版本。

# install solana
sh -c "$(curl -sSfL https://release.solana.com/v1.16.25/install)"

安装锚点

Anchor 是 Solana 开发的框架。它在很多方面与 hardhat 非常相似。

# install anchor
cargo install --git https://github.com/coral-xyz/anchor avm --locked --force

avm install latest
avm use latest

测试安装

初始化并构建一个锚点程序（用于 hello world）

Mac 用户：我们建议调用您的程序day_1而不是day1因为 Anchor 有时似乎会在 Mac 机器上默默插入下划线。

anchor init day1 # use day_1 if you have a mac
cd day1
anchor build

根据您的机器和互联网连接，此步骤可能需要一段时间。这也是您可能遇到安装问题的地方，因此如有必要，请参阅故障排除部分。

配置 Solana 在本地主机上运行

# shell 1
solana config set --url localhost

运行测试验证器节点

在新的 shell 中（而不是在 Anchor 项目中）运行以下命令。但不要关闭运行的 shell anchor build。这会在您的机器上运行本地（测试）Solana 节点实例：

# shell 2

solana-test-validator

确保 program_id 与 Anchor 键同步

返回 Anchor 项目的 shell 并运行以下命令：

# shell 1

anchor keys sync

运行测试

在 Anchor 项目中运行此命令

# shell 1

anchor test --skip-local-validator

上面的命令运行我们程序的测试。如果您尚未创建测试钱包，Anchor 将为您提供如何创建钱包的说明。我们在此不提供这些说明，因为它取决于您的操作系统和文件结构。您可能还需要通过在终端中运行来为自己空投一些本地 Sol 。您可以通过在命令行中solana airdrop 100 {YOUR_WALLET_ADDRESS}运行来获取您的钱包地址。solana address
预期输出如下：

你好世界

现在让我们让程序输出“Hello, world!”。将以下标有的行添加NEW LINE HERE到programs/day_1/src/lib.rs。

use anchor_lang::prelude::*;

declare_id!("...");

#[program]
pub mod day_1 {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        msg!("Hello, world!"); // **** NEW LINE HERE ****
        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize {}

再次运行测试之前，请终止本地验证器进程并使用以下命令重新启动它：

solana-test-validator --reset

再次运行测试

anchor test --skip-local-validator

通过运行查找日志文件

ls .anchor/program-logs/

打开该文件即可看到记录的“Hello world”

实时 Solana 日志

或者，您可以通过打开第三个 shell 并运行以下命令来查看日志：

# shell 3

solana logs

现在再次运行测试，您应该在运行的终端中看到相同的消息solana logs。

问答

为什么 declared_id! 和 msg! 后面有感叹号？

在 Rust 中，感叹号表示这些是宏。我们将在后面的教程中重新讨论宏。

我需要一个初始化函数吗？

不，这是由 Anchor 框架自动生成的。您可以随意命名。

在此上下文中，initialize 这个名称没有什么特殊之处，因此我们可以将其更改为任何我们喜欢的名称。这与其他一些关键字和语言不同，例如 main 在某些语言中是一个特殊名称，或者在 Solidity 中，constructor 是一个特殊名称。
练习：尝试将initialize中的programs/day_1/src/lib.rs和initialize中的重命名为，tests/day_1.ts然后initialize2再次运行测试。请参见下面橙色圆圈中标记的更改。

为什么我们要使用 –skip-local-validator 来运行测试？

当测试针对某个节点运行时，我们将能够查询该节点的状态变化。如果您无法让节点运行，则可以anchor test在不使用--skip-local-validator标志的情况下运行。但是，这将使您的开发和测试变得更加困难，因此我们建议让本地验证器正常工作。

故障排除

Solana 是一款快速发展的软件，您可能会遇到安装问题。我们在以下部分记录了您最有可能遇到的问题。
我们的教程系列使用以下版本编写： Anchor = 版本 0.29.0 Solana = 版本 1.16.25 * Rustc = 1.77.0-nightly
您可以通过运行以下命令来更改 Anchor 版本：

avm install 0.29.0
avm use 0.29.0

错误：solana-program v1.18.0无法构建包

error: package `solana-program v1.18.0` cannot be built because it requires rustc 1.72.0 or newer, while the currently active rustc version is 1.68.0-dev
Either upgrade to rustc 1.72.0 or newer, or use
cargo update -p solana-program@1.18.0 --precise ver

检查您正在使用的 Solana 版本solana --version。然后将该版本插入到ver上面的内容中。示例解决方案如下所示：

错误[E0658]：使用不稳定库功能“build_hasher_simple_hash_one”

如果出现以下错误：

error[E0658]: use of unstable library feature 'build_hasher_simple_hash_one'
--> src/random_state.rs:463:5
|
463 | / fn hash_one<T: Hash>(&self, x: T) -> u64 {
464 | | RandomState::hash_one(self, x)
465 | | }
| |_____^
|
= note: see issue #86161 https://github.com/rust-lang/rust/issues/86161 for more information
= help: add #![feature(build_hasher_simple_hash_one)] to the crate attributes to enable

运行以下命令：cargo update -p ahash@0.8.7 --precise 0.8.6。

来源：https ://solana.stackexchange.com/questions/8800/cant-build-hello-world

错误：部署程序失败：错误处理指令 1：自定义程序错误：0x1

Error: Deploying program failed: Error processing Instruction 1: custom program error: 0x1
There was a problem deploying: Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "" }.

如果出现此错误，则表示您的密钥未同步。运行anchor keys sync。

错误：无法发送交易：交易模拟失败：尝试加载不存在的程序

您的密钥未同步。运行anchor keys sync。

错误：您配置的 rpc 端口：8899 已被使用

当验证器在后台运行时，您anchor test没有运行--skip-local-validator。请关闭验证器并运行，anchor test或在验证器运行时运行anchor test --skip-local-validator。跳过本地验证器意味着跳过它为项目创建的临时验证器，而不是在后台运行的验证器。

错误：帐户 J7t…zjK 资金不足，无法消费

运行以下命令将 100 SOL 空投到您的开发地址：

solana airdrop 100 J7t...zjK

错误：RPC 请求错误：集群版本查询失败

Error: RPC request error: cluster version query failed: error sending request for url (http://localhost:8899/): error trying to connect: tcp connect error: Connection refused (os error 61)
There was a problem deploying: Output { status: ExitStatus(unix_wait_status(256)), stdout: "", stderr: "" }.

这意味着solana-test-validator不在后台运行。solana-test-validator在另一个 shell 中运行。

线程“main”因“调用Option::unwrap()某个None值”而惊慌失措

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /Users/username/.cargo/git/checkouts/anchor-50c4b9c8b5e0501f/347c225/lang/syn/src/idl/file.rs:214:73
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

你可能还没跑anchor build。

我在使用 Mac，出现错误：无法启动验证器：无法在测试分类账中创建分类账：块存储错误

按照此Stack Exchange 线程中的说明进行操作。

我的 Mac 上有 node.js，但是没有 corepack

运行以下命令：

brew install corepack
brew link --overwrite corepack

来源：https ://stackoverflow.com/questions/70082424/command-not-found-corepack-when-installing-yarn-on-node-v17-0-1

错误：不是目录：

BPF SDK: /Users/rareskills/.local/share/solana/install/releases/stable-43daa37937907c10099e30af10a5a0b43e2dd2fe/solana-release/bin/sdk/bpf
cargo-build-bpf child: rustup toolchain list -v
cargo-build-bpf child: rustup toolchain link bpf /Users/rareskills/.local/share/solana/install/releases/stable-43daa37937907c10099e30af10a5a0b43e2dd2fe/solana-release/bin/sdk/bpf/dependencies/bpf-tools/rust
error: not a directory:

清除缓存：运行rm -rf ~/.cache/solana/*。

错误：target/idl/day_1.json 不存在。您运行了吗anchor build？

创建一个新项目并将其命名为 day_1 而不是 day1。Anchor 似乎会在某些机器上默默插入下划线。

原文：https://www.rareskills.io/post/hello-world-solana

Solana 中的 Tx.origin、msg.sender 和 onlyOwner：识别调用者

2024-11-25　 Surou　阅读　 Solana-优秀转载　 0 评论

在 Solidity 中，msg.sender是一个全局变量，表示调用或发起智能合约函数调用的地址。全局变量tx.origin是签署交易的钱包。
在 Solana 中，没有与等效的东西msg.sender。
有一个等效的tx.origin，但是你应该知道 Solana 交易可以有多个签名者，所以我们可以将其视为具有“多个 tx.origins”。
要在 Solana 中获取“ tx.origin”地址，需要通过将 Signer 帐户添加到函数上下文来设置它，并在调用函数时将调用者的帐户传递给它。
让我们看一个如何在 Solana 中访问交易签名者地址的示例：

use anchor_lang::prelude::*;

declare_id!("Hf96fZsgq9R6Y1AHfyGbhi9EAmaQw2oks8NqakS6XVt1");

#[program]
pub mod day14 {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let the_signer1: &mut Signer = &mut ctx.accounts.signer1;

        // Function logic....

        msg!("The signer1: {:?}", *the_signer1.key);

        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    #[account(mut)]
    pub signer1: Signer<'info>,
}

从上面的代码片段来看，Signer<'info>用于验证账户结构signer1中的账户Initialize<'info>是否签署了交易。
在initialize函数中，signer1帐户从上下文中可变地引用并分配给the_signer1变量。
最后，我们使用宏并传入来记录signer1的公钥（地址），它取消引用并访问指向的实际值上的字段或方法。msg!*the_signer1.keykeythe_signer1

接下来就是针对上面的程序编写测试：

describe("Day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  it("Is signed by a single signer", async () => {
    // Add your test here.
    const tx = await program.methods.initialize().accounts({
      signer1: program.provider.publicKey
    }).rpc();

    console.log("The signer1: ", program.provider.publicKey.toBase58());
  });
});

测试中，我们将钱包账户作为 signer 传入账户signer1，然后调用初始化函数，最后在控制台上打印钱包账户，验证和程序中的一致。
练习：运行测试后，你从shell_1（命令终端）和shell_3 （日志终端）的输出中注意到了什么？

多名签名者

在 Solana 中，我们还可以让多个签名者签署一笔交易，你可以将其视为批量处理一堆签名并将其发送至一笔交易中。一个用例是在一笔交易中执行多重签名交易。
为此，我们只需在程序中的帐户结构中添加更多签名者结构，然后确保在调用函数时传递必要的帐户：

use anchor_lang::prelude::*;

declare_id!("Hf96fZsgq9R6Y1AHfyGbhi9EAmaQw2oks8NqakS6XVt1");

#[program]
pub mod day14 {
    use super::*;

    pub fn initialize(ctx: Context<Initialize>) -> Result<()> {
        let the_signer1: &mut Signer = &mut ctx.accounts.signer1;
        let the_signer2: &mut Signer = &mut ctx.accounts.signer2;

        msg!("The signer1: {:?}", *the_signer1.key);
        msg!("The signer2: {:?}", *the_signer2.key);

        Ok(())
    }
}

#[derive(Accounts)]
pub struct Initialize<'info> {
    pub signer1: Signer<'info>,
    pub signer2: Signer<'info>,
}

上述示例与单个签名者示例有些相似，但有一个明显的区别。在本例中，我们signer2在结构中添加了另一个签名者帐户（）Initialize，并在初始化函数中记录了两个签名者的公钥。

与单个签名者相比，使用多个签名者调用初始化函数有所不同。以下测试显示了如何使用多个签名者调用函数：

describe("Day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  // generate a signer to call our function
  let myKeypair = anchor.web3.Keypair.generate();

  it("Is signed by multiple signers", async () => {
    // Add your test here.
    const tx = await program.methods
      .initialize()
      .accounts({
        signer1: program.provider.publicKey,
        signer2: myKeypair.publicKey,
      })
      .signers([myKeypair])
      .rpc();

    console.log("The signer1: ", program.provider.publicKey.toBase58());
    console.log("The signer2: ", myKeypair.publicKey.toBase58());
  });
});

那么上述测试有什么不同？首先是signers()方法，它接受一个签名者数组，这些签名者将对交易进行签名作为参数。但是数组中只有一个签名者，而不是两个。Anchor 会自动将提供商中的钱包账户作为签名者传递，因此我们不需要再次将其添加到签名者数组中。

生成随机地址进行测试

第二个变化是变量，它存储模块随机生成的myKeypair密钥对（用于访问帐户的公钥和相应的私钥anchor.web3）。在测试中，我们将密钥对（存储在myKeypair变量中）的公钥分配给signer2帐户，这就是为什么它作为参数传递到.signers([myKeypair])方法中的原因。

多次运行测试，你会注意到signer1pubkey 没有改变，但signer2pubkey 发生了变化。这是因为分配给该signer1账户的钱包账户（在测试中）来自提供商，这也是你本地机器中的 Solana 钱包账户，并且分配给的账户signer2是每次运行时随机生成的anchor test —skip-local-validator。

练习：创建另一个需要三个签名者（提供者钱包账户和两个随机生成的账户）的函数（您可以随意称呼它），并为其编写测试。

唯一所有者

这是 Solidity 中常用的模式，用于将函数的访问权限限制为合约所有者。使用#[access_control]Anchor 中的属性，我们还可以实现唯一所有者模式，即将 Solana 程序中函数的访问权限限制为 PubKey（所有者的地址）。

以下是如何在 Solana 中实现“onlyOwner”功能的示例：

use anchor_lang::prelude::*;

declare_id!("Hf96fZsgq9R6Y1AHfyGbhi9EAmaQw2oks8NqakS6XVt1");

// NOTE: Replace with your wallet's public key
const OWNER: &str = "8os8PKYmeVjU1mmwHZZNTEv5hpBXi5VvEKGzykduZAik";

#[program]
pub mod day14 {
    use super::*;

    #[access_control(check(&ctx))]
    pub fn initialize(ctx: Context<OnlyOwner>) -> Result<()> {
        // Function logic...

        msg!("Holla, I'm the owner.");
        Ok(())
    }
}

fn check(ctx: &Context<OnlyOwner>) -> Result<()> {
    // Check if signer === owner
    require_keys_eq!(
        ctx.accounts.signer_account.key(),
        OWNER.parse::<Pubkey>().unwrap(),
        OnlyOwnerError::NotOwner
    );

    Ok(())
}

#[derive(Accounts)]
pub struct OnlyOwner<'info> {
    signer_account: Signer<'info>,
}

// An enum for custom error codes
#[error_code]
pub enum OnlyOwnerError {
    #[msg("Only owner can call this function!")]
    NotOwner,
}

在上述代码的上下文中，OWNER变量存储与我的本地 Solana 钱包关联的公钥（地址）。在测试之前，请务必将 OWNER 变量替换为您的钱包的公钥。您可以通过运行solana address命令轻松检索您的公钥。

该#[access_control]属性在运行主指令之前执行给定的访问控制方法。调用初始化函数时，访问控制方法 ( check) 先于初始化函数执行。该check方法接受引用的上下文作为参数，然后检查交易的签名者是否等于OWNER变量的值。require_keys_eq!宏确保两个公钥值相等，如果相等，则执行初始化函数，否则，将使用自定义错误进行恢复NotOwner。

测试 onlyOwner 功能 — 令人满意的情况

在下面的测试中，我们调用初始化函数并使用所有者的密钥对签署交易：

import * as anchor from "@coral-xyz/anchor";
import { Program } from "@coral-xyz/anchor";
import { Day14 } from "../target/types/day14";

describe("day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  it("Is called by the owner", async () => {
    // Add your test here.
    const tx = await program.methods
      .initialize()
      .accounts({
        signerAccount: program.provider.publicKey,
      })
      .rpc();

    console.log("Transaction hash:", tx);
  });
});

我们调用了初始化函数，并将提供程序中的钱包账户（本地 Solana 钱包账户signerAccount）传递给具有结构体的Signer<'info>，以验证钱包账户是否确实签署了交易。另请记住，Anchor 使用提供程序中的钱包账户秘密签署任何交易。

运行测试anchor test --skip-local-validator，如果一切正确完成，测试应该通过：

测试签名者是否不是所有者——攻击案例

使用非所有者的其他密钥对来调用初始化函数并签署交易将引发错误，因为函数调用仅限于所有者：

describe("day14", () => {
  // Configure the client to use the local cluster.
  anchor.setProvider(anchor.AnchorProvider.env());

  const program = anchor.workspace.Day14 as Program<Day14>;

  let Keypair = anchor.web3.Keypair.generate();

  it("Is NOT called by the owner", async () => {
    // Add your test here.
    const tx = await program.methods
      .initialize()
      .accounts({
        signerAccount: Keypair.publicKey,
      })
      .signers([Keypair])
      .rpc();

    console.log("Transaction hash:", tx);
  });
});