一个基于React的酶反应数据库若想让每条反应记录具备唯一归属与可交易属性，单纯套用ERC-721往往不够，因为通证元数据里很难塞下SMILES、InChIKey、反应条件等结构化科学数据。EIP9750针对这个缺口，把生物化学负载抽成独立的BiochemistryMetadata结构，并通过事件与存储优化让前端可以像操作普通NFT一样读写链上科研资产。本文围绕一次实际迁移展开，从协议层差异讲起，再说明React代码如何逐步对接合约、计算库和元数据渲染。
EIP9750与普通NFT在数据结构上的关键差异
ERC-721的tokenURI通常只返回一个JSON字符串，元数据的实际内容由链下服务器解释，这对科研数据来说不够可靠。SMILES、InChIKey和反应路径哈希这些字段一旦只放在链下，就可能被篡改或丢失，而且不同实验室之间无法直接验证某个NFT到底对应哪个分子。EIP9750在合约层面增加了metadata结构体，使这些字段成为状态变量的一部分，可以通过getter读取，而不依赖外部HTTP接口。下面是一个基本的接口定义。
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;
interface IERC9750 {
struct BiochemistryMetadata {
string smiles;
string inchiKey;
bytes32 reactionHash;
string experimentRef;
uint256 createdAt;
}
function mintWithMetadata(
address to,
BiochemistryMetadata calldata meta
) external returns (uint256 tokenId);
function getBiochemistryMetadata(uint256 tokenId)
external
view
returns (BiochemistryMetadata memory);
}
SMILES规范化是迁移中第一个容易出问题的点。同一个阿司匹林分子可以写成CC(=O)OC1=CC=CC=C1C(=O)O，也可以写成O=C(C)Oc1ccccc1C(=O)O，如果前端不统一生成Canonical SMILES，链上就会产生重复资产。EIP9750建议以InChIKey作为唯一性校验，用Biochemistry库生成，链上只存经过规范化后的字符串和哈希。这样不同实验室提交相同分子时能被识别为同一资产，或者至少能在索引层做去重。
对比传统NFT迁移时的合约接口差异，核心变化是mint函数不再是mint(address, string tokenURI)，而是mintWithMetadata(address, BiochemistryMetadata)。前端需要更新ABI和调用参数，同时Transfer事件仍然兼容，所以钱包和NFT市场无需大改。这就意味着React应用里那些依赖Transfer事件的轮询逻辑基本可以原样保留，只是写入路径要切换到新的metadata结构。
React应用迁移的合约调用与状态管理改造
迁移第一步是替换ABI和合约地址，把原有useContractWrite的调用改为传入tuple参数。wagmi对tuple类型支持比较成熟，只需要在ABI里正确声明components即可。下面这个Hook封装了铸造逻辑，返回一个mint函数给组件使用。
import { useContractWrite } from 'wagmi';
const abi = [
{
name: 'mintWithMetadata',
type: 'function',
stateMutability: 'nonpayable',
inputs: [
{ name: 'to', type: 'address' },
{
name: 'meta',
type: 'tuple',
components: [
{ name: 'smiles', type: 'string' },
{ name: 'inchiKey', type: 'string' },
{ name: 'reactionHash', type: 'bytes32' },
{ name: 'experimentRef', type: 'string' },
{ name: 'createdAt', type: 'uint256' }
]
}
],
outputs: [{ name: '', type: 'uint256' }]
}
];
export function useBiochemMint() {
const { writeAsync, isLoading, error } = useContractWrite({
address: '0xYourEIP9750Contract',
abi: abi,
functionName: 'mintWithMetadata'
});
function mint(to, meta) {
return writeAsync({ args: [to, meta] }).then(function (tx) {
return tx.hash;
});
}
return { mint: mint, isLoading: isLoading, error: error };
}
在状态管理层面，不要每次渲染都调用getBiochemistryMetadata。可以把读取结果缓存到React Query或SWR里，避免列表页出现几十个并发RPC请求。对于单个详情页，使用useEffect加mounted标志位也能满足基本需求，但更好的做法是直接用wagmi的useContractRead，它自带缓存、自动重试和区块更新监听。代码如下。
import { useEffect, useState } from 'react';
export function useBiochemMetadata(tokenId, contract) {
const [meta, setMeta] = useState(null);
useEffect(function () {
let mounted = true;
contract.getBiochemistryMetadata(tokenId).then(function (result) {
if (mounted) setMeta(result);
});
return function () {
mounted = false;
};
}, [tokenId, contract]);
return meta;
}
批量操作时还要注意RPC限额。如果详情页同时展示几十个token，不要在一个循环里发几十次getBiochemistryMetadata请求，可以使用viem的multicall聚合，把多个读取请求合并成一次。对于写入操作，一般不建议在前端做自动批量铸造，除非合约侧提供了batchMintWithMetadata这样的批量接口，否则一次一笔交易更安全，也方便用户逐条确认Gas费。
Biochemistry计算库的集成与分子数据预处理
Biochemistry计算库的核心API包括canonicalizeSmiles、computeInchiKey和hashReaction。这些函数必须在前端运行，因为EVM无法执行化学信息学规则。安装依赖后，可以在提交表单时先把原始SMILES和反应输入统一转换成链上需要的标准格式。下面这个prepareMetadata函数展示了完整的预处理逻辑。
import { canonicalizeSmiles, computeInchiKey, hashReaction } from '@biochem/core';
export function prepareMetadata(rawSmiles, reactionInput) {
const canonical = canonicalizeSmiles(rawSmiles);
const inchiKey = computeInchiKey(canonical);
const reactionHash = hashReaction(reactionInput);
return {
smiles: canonical,
inchiKey: inchiKey,
reactionHash: reactionHash,
experimentRef: '',
createdAt: Math.floor(Date.now() / 1000)
};
}
需要特别说明的是反应路径哈希。一个酶催化反应可能包含反应物、产物、溶剂、催化剂和pH条件等，如果这些字段的排列顺序不一致，同样的实验会得到完全不同的哈希。因此hashReaction内部必须对输入做固定顺序的序列化，例如按字母序排序反应物SMILES，再拼接温度、pH等数值，最后整体做一次Keccak-256。前端在调用前应确保reactionInput对象已经按预设规范构造，不要直接传用户自由填写的JSON。
在React组件中触发预处理的时机也很重要。建议放在表单提交或文件上传的处理函数里，计算完成后先用预览面板展示Canonical SMILES和InChIKey，用户确认无误后再调用mint。对于大分子3D构象计算，耗时可能达到几百毫秒甚至更久，这时可以把计算任务交给Web Worker，避免阻塞主线程导致输入框卡顿。预处理结果可以暂时放在组件state中，不要直接写入全局Store，因为不同用户对同一分子的规范化结果必须一致，不能被本地状态污染。
元数据同步与NFT渲染的性能优化
EIP9750的tokenURI通常仍然指向IPFS上的JSON，但链上metadata结构才是权威数据源。前端展示时应优先使用getBiochemistryMetadata，而不是仅依赖tokenURI去解析链下JSON。IPFS中的JSON只用于市场展示图片和基本属性，科学数据以链上结构为准。下面是一个典型的tokenURI内容示例。
{
"name": "Aspirin Molecule #12",
"description": "Canonical SMILES: CC(=O)OC1=CC=CC=C1C(=O)O",
"image": "ipfs://QmExampleHash/molecule.svg",
"attributes": [
{ "trait_type": "SMILES", "value": "CC(=O)OC1=CC=CC=C1C(=O)O" },
{ "trait_type": "InChIKey", "value": "BSYNRYMUTXBXSQ-UHFFFAOYSA-N" }
]
}
渲染优化方面，分子可视化组件通常需要把SMILES转换成SVG坐标或3D结构，如果每个token都重新解析并生成坐标，列表页会非常卡顿。可以使用React.memo缓存组件，并把SMILES解析结果存入弱缓存Map，key直接用SMILES字符串。这样相同分子的卡片只计算一次，后续渲染直接命中缓存。对于InChIKey相同但tokenId不同的NFT，还可以进一步复用分子结构图，只更新边框高亮等轻量样式。
Gas和存储成本是另一个必须考虑的环节。链上存储string非常昂贵，尤其是SMILES和实验记录。建议只在链上存哈希或短字符串，把完整实验数据放到IPFS，同时在metadata的experimentRef字段中保存IPFS CID。如果实验记录包含敏感信息，应该先做脱敏，只把哈希和脱敏摘要上链，原始数据留在受控的私有网络里。EIP9750并没有强制要求所有字段都公开，experimentRef完全可以是一个内部编号，由实验室自己的授权系统解析。
迁移过程中容易踩到的坑与安全注意
第一个常见错误是忘记做Canonical SMILES规范化，导致相同分子被重复铸造。解决方法是所有前端入口统一调用prepareMetadata，并在合约端校验smiles字段不能为空、长度不超过预设上限。第二个坑是反应哈希包含动态时间戳或随机溶剂比例，使同一反应无法复现。反应哈希必须只依赖稳定的实验参数，时间戳应该放在createdAt字段单独记录。第三个是敏感实验数据直接明文上链，一旦写入就无法删除，存在长期隐私风险。正确做法是只存内容哈希，原始数据用授权访问控制。
批量铸造时可以在合约侧增加一个batchMintWithMetadata函数，减少前端事务数量。下面是一个实现的思路，注意循环中要跳过空元数据，并限制单次批量大小防止Gas超限。
function batchMintWithMetadata(
address to,
BiochemistryMetadata[] calldata metas
) external returns (uint256[] memory ids) {
ids = new uint256[](metas.length);
for (uint256 i = 0; i < metas.length; i++) {
ids[i] = _mintWithMetadata(to, metas[i]);
}
}
安全上不能完全信任前端传入的SMILES。合约端应当限制字符串长度，并使用AccessControl控制谁可以铸造。对于要求更高的场景，可以在二级市场验证阶段引入预言机检查InChIKey与SMILES是否匹配，但不要在主网铸造流程中做这件事，否则Gas成本会高到不可接受。迁移完成后，科研数据可以像其他NFT一样确权、审计和交换，同时React应用的交互体验基本保持不变，只是底层资产模型从中心化记录变成了可验证的链上对象。