TapeAPI 1.4.0
中文
TapeAPI 1.4.0:在 1.x 基础上只做新增,按 1.0 文档写的代码无需修改。新的一致模式是实验性的,默认关闭。
新增
- TAP-10 一致模式(解析路径,实验性):
createTapeAPI({ conform: 'tap10' }),另有pin: 'tap10'和只读的api.siteStatus(目标)。TapeOut 官方在 TapeOutProtocol/TAPs 发布了 TAP-10,我们提交的 TAP 草稿一律按它写,这个模式让参考实现跟上。- 一次解析钉在同一个区块上(按各家运营方的头块取第 Q 高再减 2,按块差判断过期,不用本机时钟),区块哈希仍由各节点确认。
- 站点存储与付费合约的实现在这个区块上读取,不在已知列表里就拒绝。
- 读取
isOpened与名字的激活状态;没有开通或没有激活,会得到新的错误码SITE_STATUS(data.status为not-opened或unpaid)。 - 接受
#4246@0、tape://4246.0/、0x…#ID等输入写法。 - 激活检查只作用在解析和
siteStatus上:未激活容器的通道密钥和 TapeSend 密钥照常可读(TAP-10 §12.2)。 - 默认行为不变。 我们拿旧版本做了差分测试:1,098 个用例、7,271 次请求,除名字范围外逐字相同。
- 诊断工具和监控都会报告名字的激活状态:
tapeapi-doctor增加第 14 项检查;监控报告到期日与剩余天数。未激活只是警告,不会让监控变红。 - 新增诊断脚本
node scripts/tap10-gap.mjs:把 TAP-10 自带的测试用例跑在 SDK 上,打印哪里一致、哪里不一致(23 个可离线判断的用例:12 个一致、11 个已知差距)。
变更与修复
- 名字范围(勘误,所有模式):#ID 不超过 10^18,处理器号不超过 10^9(TAP-10 §3.1)。超出的名字在链上本来就不可能存在,现在不发任何请求就直接拒绝。
tapesend:跨链发送时,收件方端点现在建在收件方所在的链上,新增可选参数toChainId(默认等于原来的行为)。以前跨链消息会被 TAP-10 客户端判为损坏。官方的跨链消息 ID 向量能逐字复现。- 我们自己的规范文件改名为 TAPI-1、TAPI-20 到 TAPI-27,TAP 编号交给 TapeOut 的编辑分配;其中“服务身份与清单”已合并为 TAP-11(作为 Draft)。
你会注意到的变化
- 在一致模式下,我们自己的两个服务
11.1013.tape和12.1013.tape会得到unpaid,因为它们的名字还没有激活。这只约束开启一致模式的客户端,默认模式不受影响。
安装
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.4.0/tapeapi-sdk-1.4.0.tgz如果要单独安装 server,先装同一版本的 SDK tgz。完整变更见 CHANGELOG。本项目未经第三方审计。
感谢 @Theairresearch 提出最初的想法。
English
TapeAPI 1.4.0 is additive over 1.x: code written against the 1.0 docs keeps working unchanged. The new conformance mode is experimental and off by default.
Added
- TAP-10 conformance mode (resolution path, experimental):
createTapeAPI({ conform: 'tap10' }), pluspin: 'tap10'and the read-onlyapi.siteStatus(target). TapeOut published TAP-10 in TapeOutProtocol/TAPs and our TAP drafts follow it; this mode brings the reference implementation in line.- A resolution is pinned to one block (each operator's head, the Q-th highest minus 2, staleness by block distance, no local clock); the block hash is still confirmed by the nodes.
- The site store's and the payment contract's implementations are read at that block and refused when they are not on the known list.
isOpenedand the name's activation are read; a name that is not opened or not activated fails with the new codeSITE_STATUS(data.statusisnot-openedorunpaid).- The input forms
#4246@0,tape://4246.0/and0x…#IDare accepted. - Activation is judged by resolve and
siteStatusonly: an unactivated container's channel key and TapeSend key are still read (TAP-10 §12.2). - The default behaviour is unchanged. We ran a differential test against the previous version: 1,098 cases and 7,271 requests, identical except for the name range.
- The doctor and the monitor report a name's activation:
tapeapi-doctorhas a 14th check; the monitor reports the paid-until date and days left. Not activated is a warning and does not turn the monitor red. node scripts/tap10-gap.mjsruns TAP-10's own Test Cases through the SDK and prints where it conforms and where it does not (23 cases judgeable offline: 12 conform, 11 known gaps).
Changed and fixed
- Name range (erratum, all modes): #ID up to 10^18 and processor number up to 10^9 (TAP-10 §3.1). Larger names cannot exist on chain; they are now refused without a request.
tapesend: for a cross-chain message the recipient endpoint is now built on the recipient's chain, through the optionaltoChainId(default: the old behaviour). Before, a TAP-10 client read such a message as damaged. The official cross-chain message-ID vector reproduces.- Our own spec files are renamed TAPI-1 and TAPI-20 to TAPI-27, leaving TAP numbers to TapeOut's editors; the service identity and manifest was merged as TAP-11 (as a Draft).
What you will notice
- In conformance mode, our own
11.1013.tapeand12.1013.tapeanswerunpaid, because their names are not activated yet. It binds only clients that turn the mode on; the default mode is unaffected.
Install
npm install https://github.com/BruceLanLan/tapeapi/releases/download/v1.4.0/tapeapi-sdk-1.4.0.tgzTo install the server package on its own, first install the SDK tgz from the same release. The full list of changes is in the CHANGELOG. Nothing here has had a third-party audit.
Thanks to @Theairresearch for the original idea.