本文介绍了Solana区块链的账户模型,该模型将可执行代码(Programs)与程序状态(Accounts)分离,从而实现一定程度的并行化处理。讨论了账户的结构,包括Lamports、Data、Owner和Executable等字段,还介绍了Program Derived Addresses (PDAs) 的概念及其在Solana中实现哈希表类似结构的方式。
这是关于区块链的系列文章的一部分。如果你是第一次看到这篇文章,我强烈建议从本系列文章的开头开始阅读。
在上一篇文章中,我们开始涉足 Solana 领域,探讨了该区块链如何将加粗时间加粗的概念融入其中,从而提供了一种简单而智能的方式来为交易添加时间戳。
但这并不是 Solana 为本系列文章带来的唯一创新概念。
你看,当我们研究 加粗智能合约加粗 时,我们花了很多精力来解释 以太坊虚拟机 (EVM) 的工作原理 —— 一组定义完善的规则,允许我们编写程序。
然而,并非所有区块链都遵守这些规则,有些区块链已经尝试了其他方法,以寻找更方便 —— 且有望更好 —— 的方式来实现可编程性。
Solana 恰好是其中一个区块链。今天,我们将看看他们的解决方案!
不过,在我们深入研究任何可编程性之前,我们需要了解更多关于这个区块链的知识。
特别是,我们关心如何处理加粗账户加粗。与任何 EVM 区块链一样,Solana 也会将与单个加粗地址加粗关联的所有数据放入一个账户中。
然而,这里有一个关键的区别:虽然 EVM 区块链将加粗代码加粗 和 加粗状态加粗 捆绑在智能合约账户中,但 Solana 有意将加粗可执行代码加粗 与 加粗程序状态加粗 分离。第一部分存储在 加粗程序加粗 中,而第二部分则位于 加粗账户加粗 中。
显而易见的问题是 为什么要这样做?这样做有什么好处?
这可能并不明显,但答案很简单:它允许一定程度的加粗并行化加粗。
为了解释我的意思,让我们快速看一个例子。
假设你有两个事务存在于同一个程序上。但是事务 1 仅触及位于帐户 1 中的状态,而事务 2 仅影响位于帐户 2 中的状态。因此,由于它们是完全独立的,Solana 可以同时——并行地运行上述事务!
EVM 架构不允许开箱即用,因为智能合约及其状态是加粗紧密耦合在一起的加粗,并且很难确定两个事务在一般设置中是否完全独立。
我们稍后会介绍程序 —— 但首先,让我们放大 Solana 中 加粗账户加粗 的概念。
Solana 中的每个 加粗实体加粗 都是一个账户,这应该不会让我们感到惊讶 —— 毕竟,EVM 系统也发生了同样的事情(使用 EOA 和合约账户)。
就其结构而言,它们是非常简单的:我们需要表示它们的只是一些键/值对(同样,没有什么新的),它们是:
到目前为止,一切都很好!我们已经经历了一些战斗,所以关于这些想法应该没有什么神秘之处 —— 事实上,它们对你们来说根本不应该感到陌生。
如果是的话,去读读之前的文章!
说真的,去读它们
好的,假设我们想开始使用 Solana,所以我们需要我们自己的帐户!
当然,我们需要一个 加粗密钥对加粗(又名私钥和公钥)才能签署交易,当然还有与所述密钥对关联的 加粗地址加粗。
Solana 使用 ed25519 曲线,这是相当标准的。
我想你可能会期望一个帐户的 加粗所有者加粗 是控制它的公共地址,对吧?至少这是我的直觉。想象一下,当我得知 我错了 时的惊讶。
你说什么?
是的!Solana 中的所有 加粗钱包账户加粗 都归所谓的 加粗系统程序加粗 所有。
这个系统程序是 唯一可以创建账户的程序,它还包含执行用户签名交易的逻辑。
它还做 其他几件事。
我知道。说你不 加粗拥有加粗 你的钱包有点奇怪。事实是,这只是作为交易处理的单一入口点,但实际上,所有交易都必须 加粗签名加粗 —— 没有所述签名交易,系统程序无法更改任何状态。所以你 确实拥有 你的帐户,但通过你的 私钥!
酷!我们现在有了一个钱包。那么程序呢?
进入有趣的部分!
加粗程序加粗 是 Solana 版本的智能合约。正如你对所有序言的期望一样,这些只是 executable
字段设置为 true 的 accounts 。
我们需要将 加粗字节码加粗 存储在某个地方,对吧?猜猜它会存储在哪里?
当然是在 data
字段中!毕竟,字节码只是一个巨大的字节数组。
我们现在可能有的另一个问题是 谁拥有程序账户 。我们不会玩任何猜测游戏,因为它根本不明显。
程序是由 加粗其他程序_ 创建的 —— 特别是由一组称为 加载器程序 的程序创建的。或者, 几乎。
正如我们已经知道的,账户需要由系统程序创建。但是,这些加载器程序被 分配 新账户的所有权,然后它们才将 data
字段设置为程序的字节码。
有点像某种安装程序。哦,它还将
executable
字段设置为 true!
同样,最终结果是合约 不归 你(部署者)所有。这没关系 —— 这只是区块链的架构决策,并允许它以有组织的方式执行交易。
如果这些加载器程序可以设置字节码... 这是否意味着 Solana 程序是 加粗可升级的加粗?也就是说,它们的代码可以 加粗更改加粗 吗?
简而言之:是的!虽然,在 某些条件下:必须使用最新的加载器程序,并且只有在设置了 升级权限 时,我们才能执行升级。程序默认是 可变的,这意味着升级权限是在部署时设置的(设置为部署者的地址),并且该账户有权限 更改代码。
稍后,可以将权限设置为 none,使程序 不可变。
这听起来可能不太可靠,特别是在我们经历了以太坊的探险之后,以太坊假设 不可变性 。但是,我们可以通过 代理和委托调用 在 Solidity 中构建可升级合约 —— 因此 从功能上讲 ,这没什么新鲜的。
但是,不可变程序很重要:它们对于建立 加粗信任加粗 至关重要。作为用户,我们希望程序以一致的方式运行,并且当我们转移资金时不会发生奇怪的事情 —— 尤其是不允许发生 恶意活动 。因此,虽然在程序的开发阶段更改代码是很正常的,但我们通常希望在生产中 使它们不可变 。
解决了这个问题,让我们看看程序 实际上是如何工作 的。
与程序交互涉及创建 加粗交易加粗,我相信你一定期望如此。但请记住 —— 程序和状态在 Solana 中是 分开存储的 ,这意味着仅仅指定要调用的程序在区块链中是 不够的 。
每个程序都有自己的 加粗地址加粗,我们将在构建的交易中使用它。此外,我们还需要指定程序应在哪些 加粗账户加粗 上运行 —— 我们想要修改的 状态 。
但是等等... 任何程序都可以随意更改任何帐户的状态吗?听起来像是 灾难 的根源。必须 对程序可以做什么施加一些限制,对吗?对吗?
嗯,当然!否则,系统将 加粗一片混乱加粗。
这正是所有权系统真正发挥作用的地方:最重要的限制是,执行程序 拥有 它想要修改其状态的帐户。
与 EVM 进行比较可能有助于巩固这个想法。可以部署多个智能合约实例,但实际上,它们都将共享相同的逻辑。这样做有点 低效,因为我们正在占用区块链中的空间来一遍又一遍地存储相同的代码。
在 Solana 中,由于状态 未绑定 到逻辑,我们可以简单地重用一个程序,并且仅为新状态创建新帐户,从而有效地 重用代码!
所有这些信息都是非常理论化的,因此我建议我们看一个实际例子,看看我们可能遇到任何其他问题。
让我们尝试构建一个 加粗代币程序加粗,类似于 ERC20。
Solidity 为此提供了 映射 —— 但 Solana 中等效的东西是什么?我们只有 帐户,并且没有像映射那样丰富的数据结构。那我们该怎么办?
我们的目标是跟踪每个用户拥有多少代币。所以这是一个想法:让我们创建一个 单独的帐户 来存储 每个用户的余额 。
但是…… 哪些帐户?我的意思是,我们不能只是选择随机地址,对吗?
想象一下,每个用户都必须记住他们拥有的每个代币的帐户地址。这将是糟糕的用户体验!
理想情况下,我们希望开发一种 系统 以确定性方式获取这些用户余额帐户,不仅用于初始余额分配,还用于处理交易。
幸运的是,Solana 的人在设计系统时也发现了这个问题,并提出了一个优雅的解决方案:加粗程序衍生地址加粗,或简称为 加粗PDA加粗。
回想一下我们研究以太坊时,我们已经 在某种程度上面临 这个问题。映射只是一种方便的抽象 —— EVM 不得不在后台进行一些黑魔法来计算实际数据的存储位置。
现在的故事并没有太大的不同,但它具有一些不同的味道。加粗PDA加粗 本质上是一种将一些密钥(如用户地址、代币 ID 或任何其他值)和一些其他程序特定的值(称为 种子 )放入 加粗确定性混合器加粗 的方法。这意味着每个程序都将知道在何处存储每个标识符(在我们的例子中是地址)的数据,并且我们无需记住任何内容 —— 程序可以为我们计算出来。
种子可以是字面上的任何东西 —— 它只是一个字节数组!
现在,我们知道的最简单的确定性混合器类型是 哈希函数。我们可以走这条路,是的,但这些被称为程序衍生 加粗地址加粗,而不是 加粗哈希加粗。
我会说,非常可疑。
当然,确实发生了一些奇特的事情。
我们首先确实使用 Solana 选择的哈希函数 SHA-256 对我们的目标地址和种子进行哈希处理 —— 与其历史证明中使用的是相同的哈希函数。
这就是有趣的地方:SHA-256 的输出正好是 32 字节,这恰好与 ed25519 曲线点 的大小相匹配。
为什么这很重要?因为如果我们的哈希 位于曲线上 ,那么这意味着它是一个有效的 公钥 。
为了避免混淆,与实际私钥关联的 Solana 地址只是 base58 编码的公钥。
那不好 —— 这意味着存在一些 私钥 可以控制上述帐户。请记住,我们正在尝试生成帐户以存储程序的信息,该程序应该是对上述新帐户的唯一权限。但是,如果有人有可能控制它,那么这将破坏 Solana 的所有执行保证!
为了缓解这种情况,PDA 使用了一个 加粗巧妙的技巧加粗。在生成过程中,如果哈希恰好是一个有效的曲线点,那么它将被 丢弃,并且该过程通过添加一个 小颠簸 重新开始。此颠簸的工作方式与 盐 或 随机数 本质上相同 —— 并且它将有助于生成一个完全不同的哈希。我们重复此过程,直到我们得到一个 不是 曲线上的有效点的哈希 —— 就是这样!一个有效的地址,没有私钥。
好的
拼图的最后一块是,该颠簸是从一个 整数序列 获得的,范围从 255 到 0。因此,它不需要存储在任何地方 —— 每次需要计算 PDA 时,都可以执行相同的确定性过程,并在 第一个 有效颠簸 处停止。
尽管如此,我认为为了提高效率,有时会在 加粗本地缓存加粗 颠簸。
这就是你所拥有的!Solana 中的哈希图式结构,仅使用其原生元素!这不是很棒吗?
当然,关于 Solana 生态系统还有很多要说的。
我的目标不是涵盖每个协议的每个细节 —— 否则,我根本无法 完成 这个系列!
如果你有兴趣深入了解,一些值得探索的主题包括 跨程序调用(程序如何调用其他程序)、Solana 运行时事务处理管道、提供核心区块链功能的各种本机程序,或很酷的功能,如对 部分签名 和 费用赞助 的支持。
尽管如此,我们在过去的这两篇文章中已经涵盖了很多内容。我相信我们已经触及了 Solana 带来的两个最关键的发展:它的 历史证明 和现在的帐户模型,这标志着我们首次脱离 EVM 模型。
有时,这种帐户架构和所有周围的程序套件被称为 Solana 虚拟机,或 SVM。我认为这个术语没有像 EVM 那样流行,但它仍然反映了完全不同的架构。
也许是因为它与 SVM 的成熟技术首字母缩写相匹配?谁知道呢。
我们看到了一些它的优势:允许在程序与存储在独立帐户中的独立状态交互时进行一些本机并行执行。这很关键,因为并行化是 可扩展性 的一个重要特征。我们很快就会谈到这一点。
总而言之,Solana 引入了一些有趣的想法,这些想法不断地在我们区块链之旅中滋养我们。
虽然我们现在将离开这个生态系统,但我鼓励你继续做一些研究,因为这是 最大的区块链之一 —— 所以绝对值得关注!
说到新想法,我想在下一篇文章中简要介绍一下行业中的其他一些开创了新概念的参与者,以寻求改进这个不断发展的区块链世界。
我们很快就会见面!
- 原文链接: medium.com/@francomangon...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!