文章里很多内容都是在讲unikraft编译构建过程……实际上如何和区块链结合的内容微乎其微。不理解。

所以节省时间没记录完整笔记。

本文旨在提出一种可行且易于实现的解决方案，期望不仅提升单个节点，而且优化整个区块链架构。

通过采用 unikernel（单镜像内核）技术，使区块链节点更快、更安全且更健壮。

现状

自区块链诞生以来一直困扰其发展的一个问题便是可扩展性

文献指出，许多研究都在讨论这一以多种形式出现的先天性问题，例如低效的共识机制（例如比特币的工作量证明，尽管它是此类上下文中最常见的机制之一）、有限的区块大小导致较高的交易延迟，或交易被留在队列中最终造成较低的吞吐量等问题。

存储容量与能耗。

现有解决方案

分片

Layer-1：对区块链结构进行修改

Layer-2：在链外实现

链下并行处理

账本状态与交易执行被移至链下，而交易验证仍在链上进行。

使用并行处理的区块链平台例子还有 Solana

之后要看Solana

Rollups

Rollups 定义了一种将区块链节点需要执行的部分处理负载移至第二层网络的方法。交易在第二层被处理后，其相关信息会被“汇总”回主链层。Rollup 系统的实现依赖于“第一层”智能合约，用户通过与这些合约交互进行交易，从而获得可在第二层网络上使用的代币。

Rollup 主要分为两大类：乐观（optimistic）与零知识（zero-knowledge）。\cite{ref15} 一个重要且采用 Rollups 的区块链网络是以太坊，具体为乐观型 Rollups——之所以称为“乐观”，是因为其假设已处理的交易为有效。将乐观 Rollups 与链下（off-chain）实现区分开来的，是以太坊所提供的正确性保障；若出现错误交易，将会施加惩罚措施以保证系统正确性。\cite{ref16}

Unikernel vs 容器

在另一篇论文中，作者发现 OSv 是其测试环境中唯一稳定的平台。尽管技术上支持 Python，但要使其正确运行仍需对 OSv 源码做改动。\cite{ref18} 他们在 unikernel 与容器之间的性能评估显示：在基于 Type-I 虚拟机监控器（hypervisor）的单核模式下，unikernel 在速度与响应时间上均优于容器。对 REST 服务的压力测试表明，Java、Python 与 Go 的 unikernel 性能均优于对应容器：Java 与 Python 提升约 16%，而 Go 的提升高达 38%。然而，在重负载场景下，容器似乎更具优势——此前提到的每种 unikernel 在重负载下均未表现出性能增长，尤其是 Python 的 unikernel 仅达到其等价容器性能的 50%。