https://www.azuki.com/erc721a

简介

• ERC721A 是 IERC721 的一种实现，在单笔交易中 mint 多个 NFT 可显著节省 gas。

• Azuki 合约将使 mint 多个 NFT 的成本与 mint 单个 NFT 的成本基本相同。

• 我们与外部安全顾问 (Caribou) 合作，以确保我们的方法是可行的。

• 我们鼓励更广泛的社区采用这种实施方式来为他们的用户节省 gas 成本。

起因

几个月来，以太坊的 Gas 价格一直居高不下，开发社区需要适应。当流行的 NFT 项目开始出现时，gas 价格飙升，导致整个生态系统支付数百万的 gas 费用来进行交易。在 Azuki，我们正在与我们的社区一起为 Metaverse 建立一个品牌。开发团队的重点是优化我们的合约，并使我们的社区在 mint 时尽可能少地花费 gas 费用。

我们没有使用 OpenZeppelin 流行的 IERC721 和 IERC721Enumerable 默认实现，而是编写了我们的版本（在本文的其余部分，我们将其称为 ERC721A）并很高兴地宣布，Azuki 合约的确能够实现 mint 多个 NFT 与 mint 单个 NFT 的 gas 成本相同。

性能比较

我们比较了 mint 的 gas 成本和价格，比较了 OpenZeppelin 的 ERC721Enumerable 与 ERC721A。在我们的比较中，使用了相同的应用程序逻辑，唯一的区别是调用了 _safeMint 函数。

假设成本时 300 gwei 和 3500 美元/ETH。这些只是估计值，很难预测 mint 时的 gas 和 eth 价格（目前在撰写本文时为 120 gwei）。

这是如何实现的？

我们在下面详细介绍了我们所做的三个主要优化。虽然我们试图让它尽可能清楚 - 这篇文章的其余部分确实假设您已经了解 Solidity 和 OpenZeppelin 的 ERC721 / ERC721Enumerable 实现。

优化 1 - 从 OpenZeppelin (OZ) ERC721Enumerable 中删除重复存储

IERC721Enumerable 的广泛使用的 OZ 实现包括每个令牌元数据的冗余存储。这种非规范化方法以写入函数的显着成本优化读取函数，这并不理想，因为用户不太可能为读取函数付费。此外，我们的令牌从 0 开始按顺序编号这一事实让我们从基本实现中删除了一些冗余存储。我们强烈建议所有新发布的产品如果正在寻找大赢家，请仔细检查此文件。

优化 2 - 每批铸币请求更新一次所有者的余额，而不是每个铸币的 NFT

假设 Alice 有 2 个代币并想再购买 5 个。在 Solidity 中，更新存储值需要消耗 gas。因此，如果我们在存储中跟踪 Alice 拥有多少代币，通过一次更新将 Alice 的持有量从 2 直接更新为 7 会更便宜，而不是将该值更新 5 次（每个额外的代币一次，从 2 到 3、3到 4 等）。

虽然这是一个相对简单的概念，但 NFT 领域中的绝大多数批量 mint 还没有采用这一点，因为 OZ 默认实现不包括批量 mint API，并且很容易从货架上获取现有解决方案而不对其进行调整.我们强烈建议所有支持批量 mint 的项目都考虑这个技巧。

优化 3 - 每个批处理 mint 请求更新一次所有者数据，而不是每个 minted NFT

这在本质上与优化 2 相似。假设 Alice 想购买 3 个代币 - 代币 #100、#101 和 #102。与其将 Alice 保存为所有者 3 次（每次都花费我们gas），我们可以改为仅保存所有者值一次，在语义上暗示 Alice 拥有所有 3 个令牌。

如何？假设 Alice 铸造了代币 #100、#101 和 #102，而 Bob 铸造了代币 #103 和 #104。内部所有者状态如下所示：

这里的关键是，如果我们想查看谁拥有 #102，我们实际上不需要将 Alice 显式设置为 #102 的显式所有者来执行此操作。我们可以更改 ownerOf 函数来执行以下操作：

如果我们将其实现更改为递减，直到找到明确的所有者集，ownerOf 仍能按预期工作。

虽然这些延迟的所有者写入可能仍会在代币生命周期的后期发生，但我们仍然预计从整体上节省大量的净费用，因为这会减少 mint 时的 gas 花费，从而降低 mint 时整个生态系统的集中 gas 峰值的严重性。这种优化涉及一些额外的逻辑，尤其是在传输方面，但超出了本博客的范围。合同将在 mint 时间之前公开，开发人员将很乐意回答任何问题并进行讨论！

写在最后

我们相信，铸造多个 NFT 的 Gas 成本低于我们在该领域所见的任何费用。我们的外部安全顾问 (Caribou) 已审查了合同，以确保我们的方法是合理的，以便用户自信地享受这些天然气节省。所有项目都应努力最大程度地减少 gas 负担，并尽可能为其社区迈向 O(1)。我们鼓励该领域的其他项目采用 ERC721A 标准进行任何公开销售，允许在一次交易中铸造多个 NFT。有关合同的任何问题，无论是关于代码还是关于为您的项目实施它，请通过 Twitter 私信联系 @locationtba 或 @2pmflow。

Azuki 将于太平洋标准时间 1 月 12 日上午 10:00 开售，到时候见。

WASM（WebAssembly）是一种用于堆栈式虚拟机的二进制指令格式。它是是一种文件格式标准，不是特定的虚拟机实现，因此有各种 compiler、interpreter 以及 runtime，如wastime、Wasmer、V8、 Lucet、WAMR、wasm3。

WASM 在设计之初，考虑了以下几点：🔗

• 高效和快速：体积小，加载速度快。可以流式加载，边下载边初始化，减少时间和内存占用。理论上可以达到原生的运行速度。

• 安全：WASM 描述了一个内存安全的沙箱执行环境，甚至可以在现有的 JavaScript 虚拟机中实现。

• 开放可调试：可以翻译为可读的文本格式.wat（可以理解为 WASM 平台的汇编语言），配合 source map 方便调试。

• Web 标准：模块能够传入和传出 JavaScript 上下文，并通过 JavaScript 访问 Web API 来访问浏览器功能。同时也支持非浏览器环境中运行。

但也有以下限制：

• 基础数据类型只有 i32、i64、f32、f64。高级数据结构（如：字符串）每种语言需要自己实现。🔗

• 只能进行同步计算，不支持异步函数。

• 对于 Go、Python 这种带运行时的语言编译到 WASM，需要将运行时一起打包，生成的文件体积较大。

接下来我们将使用 Node.js（V8）作为 runtime 语言，AssemblyScript 作为编译到 WASM 的语言，来做点实验。

AssemblyScript

A language made for WebAssembly.

对于很多在 WASM 诞生前就已经存在的语言，WASM 就像 x86、ARM64 一样，只是一种新的 platform target。

而 AssemblyScript 是一个为 WASM 而生的语言，目前只能编译到 WASM。它的语法是一种 TypeScript 的变体，但实际写起来时，有时却要像写 C 语言那样思考。

AssemblyScript 项目搭建请参考Quick Start。

a+b

我们来写一个简单的 a+b，为什么不是 hello world？因为字符串在 WASM 里是高级数据结构。我们先从最简单的 i32 开始：

// sum.ts
export function sum(a: i32, b: i32): i32 {
  return a + b;
}

编译后得到一个二进制文件sum.wasm，和一个文本文件sum.wat。两者可以使用wabt互相转换。我们以文本格式为例：

; sum.wat
(module
  (type $t0 (func (param i32 i32) (result i32)))
  (func $sum (type $t0) (param $p0 i32) (param $p1 i32) (result i32)
    local.get $p0
    local.get $p1
    i32.add)
  (memory $memory 0)
  (export "sum" (func $sum))
  (export "memory" (memory 0)))

如果学过汇编，不了解 WAT 语法也可以看懂个大概。值得注意的是export "memory"，这是 WSAM 把内存暴露给 runtime，后面的例子会用到。

接下来在 Node.js 中调用：

import fs from "fs";

const file = await fs.promises.readFile("./sum.wasm");
const module = new WebAssembly.Module(file);
const instance = new WebAssembly.Instance(module);

console.log((instance.exports.sum as Function)(1, 2));
// stdout: 3

只需几行代码就完成了调用，并输出了预期的结果。

'hello, world!'

来看看字符串是如何在 WASM 与 runtime 之间传递的。

// hello-world.ts
export function hello_world(): string {
  return `hello, world!`;
}

编译后得到：

; hello-world.wat
(module
  (type $t0 (func (result i32)))
  (func $hello_world (type $t0) (result i32)
    i32.const 1056)
  (memory $memory 1)
  (export "hello_world" (func $hello_world))
  (export "memory" (memory 0))
  (data $d0 (i32.const 1036) ",")
  (data $d1 (i32.const 1048) "\01\00\00\00\1a\00\00\00h\00e\00l\00l\00o\00,\00 \00w\00o\00r\00l\00d\00!"))

在 Node.js 中调用：

import fs from "fs";

const file = await fs.promises.readFile("./hello-world.wasm");
const module = new WebAssembly.Module(file);
const instance = new WebAssembly.Instance(module);

console.log((instance.exports.hello_world as Function)());
// stdout: 1056

结果不是"hello, world!"，而是一个数字，发生什么事了？

这个数字其实是一个指针的地址，它指向了一个字符串。通过string-layout这篇文档，我们可以知道 AssemblyScript 的字符串是如何在内存中排布的，因此我们可以编写代码把字符串取出来。

// ...
const offset = (instance.exports.hello_world as Function)();
const memory = instance.exports.memory as WebAssembly.Memory;
const buffer = Buffer.from(memory.buffer);
const len = buffer.readUInt32LE(offset - 4);

console.log(buffer.slice(offset, offset + len).toString());
// stdout: hello, world!

WASM 使用的是little endian byte order，因此我们用readUInt32LE而不是readUInt32BE。

`hello, ${str}!`

我们已经学会把字符串从 WASM 传到 runtime 中，接下来我们学习反向操作。

// hello.ts
export function hello(str: string): string {
  return `hello, ${str}!`;
}

使用编译参数：

asc hello.ts --use abort= --target release

我们只改了几个字符，但这次编译出的 hello.wat 已经有 400+行。

在前两个例子中，内存是静态的，而在这个例子里我们进行了字符串拼接，就涉及到了内存的动态管理。因此 AssemblyScript 需要把内存回收运行时打包进 WASM，就增加了文件体积。

// ...
const memory = instance.exports.memory as WebAssembly.Memory;
const buffer = Buffer.from(memory.buffer);
const str = "wasm";
const ptr = 1024;
buffer.writeUInt32LE(str.length, ptr - 4);
Buffer.from(str).copy(buffer, ptr);
const offset = (instance.exports.hello as Function)(ptr);
const len = buffer.readUInt32LE(offset - 4);

console.log(buffer.slice(offset, offset + len).toString());
// stdout: hello, wasm!

这里的ptr = 1024是一个危险的做法，这个例子里我们假定 WASM 不会使用第 1024 个字节附近的内存，实际使用中不能这么写，这样可能会覆盖掉 WASM 所需要的数据，使 WASM 运行异常。

AssemblyScript 提供了Loader，封装了这种高级数据结构传递的方法；Rust 也提供了wasm-bingen，可以生成.js和.d.ts文件，在 js 代码中直接 import 就可以调用 Rust 编写的 WASM 模块中的函数。

到这里，相信你对如何在 WASM 与 runtime 之间传递数据已经有了初步了解。

DELL P2415Q

23.5 寸 4K IPS 屏 ，2015-08 购买，3000 元。

当时 4K 显示器刚开始普及，可选的型号不多。还专门为这个显示器配了一个台式机，i3-2130 处理器，R9 Nano 显卡，可以畅玩 4K 全高特效 DotA2。

后来公司采购显示器我就推荐的这款型号，办公用非常不错。

这台显示器后来卖给公司了。

ELSA E32B700BD

31.5 寸 4K VA 屏 ，2017-06 购买，2199 元。

是个杂牌显示器，但性价比非常高，VA 屏色彩艳丽。当时合租的室友看到后也买了一台。

这台显示器卖给同事了，但他使用一年后就坏了。

LM315WR1 SSA1 B1

31.5 寸 4K IPS 屏 ，2018-03 购买，显示屏+驱动板 2180 元。

这是 LG 32UD99 同款面板，不带外壳，使用一块亚克力背板链接屏幕与驱动板。

在 macOS 下驱动有点问题，无法输出 4K，需要在 /Library/Displays/Contents/Resources/Overrides/ 目录下放一个配置文件才能正常使用。

这台显示器也卖给同事了。

FIGHT K27MD5KAL

27 寸 5K IPS 屏 ，2019-03 购买，2999 元。

用了 5 年的 4K 显示器了，想体验一下更高的分辨率。

这款显示器采用的是 LG UltraFine 5K 同款面板，但是需要两根 DP 线才能驱动 5K 分辨率。使用一段时间后发现显示器有残影，从白色界面切换到灰色界面时最为明显，过半分钟左右消失。除了这个问题之外其他方面都还挺不错的。

这台目前在家里使用。

Geekon 28

28 寸 4.5K IPS 屏 ，2021-04 购买，6100 元。

这款显示器采用的是 Surface Studio 2 同款屏幕，分辨率 4500x3000，屏幕比例 3:2。

冲这奇葩的分辨率而购买的，买回来刚开箱感觉非常惊艳，但点亮后就发现屏幕四周亮度衰减非常明显。最致命的是屏幕中间纵向有几个像素不见了，老板说是驱动板的 bug，在联系厂家修复。我去一家制作驱动板的店铺咨询，给到的答复是目前无解。

于是我用了一天就退货了。

Pro Display XDR

32 寸 6K IPS 屏幕，2021-04 购买，纳米纹理玻璃款加支架 55798 元。

购买后等了一个多月才送到，怀疑是现做现卖。

在 Youtube 上找了几个 4K HDR 视频看。非全屏状态下，使用 Chrome 时，视频那个区域的亮度和其他部分不一样；使用 Safari 时，整个屏幕的亮度随视频内容而变化。明暗对比强烈，色彩鲜艳。

播放本地视频时，iina、VLC、Movist、Optimus Player 均无法正常 HDR。按照网上的说法，我使用ffprobe -v error -show_streams -select_streams v:0 -of json -i video.mkv命令查看视频文件的色彩空间是BT.2020，说明确实是 HDR 视频文件，不知问题出在哪里。我又用ffmpeg -i video.mkv -c copy -tag:v hvc1 video.mp4把它转成 MP4 封装，使用 Quick Time 播放，仍然看不出有 HDR 的效果。

LG OLED48CXPCA

48 寸 4K 120Hz OLED 屏幕，2021-08 购买于闲鱼，7500 元。

买电视当显示器用，性价比非常高，几乎占满整个桌面，使用体验非常震撼。美中不足的是只有 HDMI2.1 接口，目前显卡太贵不想买，我手中的设备只能支持到 4K 60Hz HDR 或 4K 120Hz 420，要么损失帧率，要么损失色彩。

即便如此表现依然非常亮眼，屏幕表现不必多说，就讲讲其他的体验。电视开机很快，小于 10s；WebOS 很不错，没有广告，不卡顿；支持 AMD Freesync Premium 可变刷新率；作为一款电视来说延迟很低，特别是在 120Hz 刷新率下，但 60Hz 下打 CS 还是不太行的；使用中还是会有意识避免长时间显示同一画面，从而降低烧屏概率，有一点不舒服。

最近参与制作了即刻里的一个小功能“我的持仓”。其前端主要分为两部分：一部分是即刻个人主页下的“小卡片”，另一部分是点击小卡片后跳转到的网页。我们主要来讲讲这个小卡片是如何实现的。

• 小卡片实际上是一张 SVG 图片，放在整个卡片列表中的一个 <img /> 标签里

• 为什么不以 SVG DOM 的方式渲染？这样做的话，卡片列表（上图黄框部分）和卡片内容（上图红框部分）代码要放在同一个项目中，“我的持仓”业务逻辑和即刻的业务逻辑就耦合了。

• 为什么不用 PNG 图片？因为图片中含有文字，PNG 图片无法适配不同手机的不同字体。

Figma 导出 SVG

导出时注意不要勾选 Outline Text，该选项会把 text 变成 path，也就是把字体当作矢量图来画。但是在我们的渲染中需要 text 作为变量，因此不要勾选。

React 渲染 SVG

React 本身就支持 SVG 渲染，把刚才导出的 svg 代码复制粘贴成为一个 React Component

export const SvgBox = () => (
  <svg
    width="100"
    height="100"
    viewBox="0 0 100 100"
    xmlns="http://www.w3.org/2000/svg"
  >
    ...
  </svg>
);

Next.js SSR

使用 Next.js 的约定式路由，新建一个页面文件，使用 renderToStaticMarkup 和 getServerSideProps 进行服务端渲染。请求这个页面时，返回的是 SVG，而不是 HTML。

import type { GetServerSideProps } from "next";
import { renderToStaticMarkup } from "react-dom/server";

export default function SvgPage() {
  return null;
}

export const getServerSideProps: GetServerSideProps = async ({ res }) => {
  res.setHeader("Content-Type", "image/svg+xml");
  res.write(renderToStaticMarkup(<SvgBox />));
  res.end();
  return {
    props: {},
  };
};

之后所需要做的事情就是根据业务逻辑给 <SvgBox /> 组件传入变量，就像写普通 React 组件一样。

嵌入图片

值得注意的是，为了在 Android 系统上显示 Apple Emoji，小卡片第二行行首的 emoji 不是字符，而是 PNG 图片。

base64 encode

在 <img /> 标签里显示的 svg 不能再请求外部资源，所以我们需要把 PNG base64 encode 后作为 Data URL 传入 SVG 的 <image /> 标签中，而不能只传一个 url。

AVIF 和 WebP

PNG 图片 base64 后体积太大了，因此我为每张 emoji PNG 都准备了对应的 AVIF 和 WebP 版本，根据 req.headers.accept 来给 SVG 嵌入不同格式的图片