node 正在参加 2021 年度 OSC 中国开源项目评选,请投票支持!
node 在 2021 年度 OSC 中国开源项目评选 中已获得 {{ projectVoteCount }} 票,请投票支持!
2021 年度 OSC 中国开源项目评选 正在火热进行中,快来投票支持你喜欢的开源项目!
2021 年度 OSC 中国开源项目评选 >>> 中场回顾
node 获得 2021 年度 OSC 中国开源项目评选「最佳人气项目」 !
授权协议 MIT License
操作系统 跨平台
软件类型 开源软件
所属分类 Web3区块链
地区 不详
投 递 者 首席测试
适用人群 未知
收录时间 2021-11-30


The Node

CircleCI Renovate enabled semantic-release Docker Automated build Join the chat at

The Node allows you to timestamp documents in a decentralized manner.

It's built on top of the Bitcoin blockchain and IPFS.


How to Run the Node

To run the Node, clone this repo, and make sure you have Docker and docker-compose installed.

Clone the repo:

git clone
cd node

To start the Node environment, run:

docker-compose up --build

Using the instructions above, new blocks have to be generated manually. This is often desirable during development. To have blocks automatically generated, follow the instructions below instead to mine a new block every 5 seconds.

  $ cp docker-compose.override.yml.example docker-compose.override.yml
  # Edit docker-compose.override.yml and uncomment
  # the `regtest-watcher` service in `docker-compose.yml`
  $ docker-compose up --build

You only need to run docker-compose build to create or update the Docker images, and docker-compose up -d to start them. To shut everything down, it is recommended to use docker-compose down --volumes to stop the running containers and clear any data. If you wish to keep data between invocations, use docker-compose down.

You can also docker-compose exec mongo bash and docker-compose exec ipfs sh to run the mongo shell or ssh into the IPFS container.


The Node depends on RabbitMQ, IPFS, Bitcoin Core and MongoDB.

These dependencies are setup automatically when you run docker-compose.


The Node comes with a default configuration that works out of the box, which can be found here:

By default, anchoring to the blockchain is disabled (enableAnchoring: false). If you want to enable blockchain anchoring, you will need to the Bitcoin Core dependency to be running with a funded wallet so that it can pay the Bitcoin network transaction fees (either for testnet or real Bitcoin for mainnet).

You can change any configuration by passing configuration values via environment variables. The keys of these environment variables are always the SCREAMING_SNAKE_CASE equivalent of the configuration options listed in the default configuration. For example, the RabbitMQ URL (rabbitmqUrl) can be set with the RABBITMQ_URL environment variable.

Note: will NOT reload the configuration while it's running if you change it. You will need to restart the Node for configuration changes to apply.


Currently, the Node exposes four endpoints.

GET /works?issuer=xxx&limit=x&offset=x

Returns a paginated array of signed verifiable work claims.

Accepts the following query parameters:

  • issuer: string. If present, will only return works issued by this issuer.
  • limit: number. Maximum number of results to return per request. Defaults to 10.
  • offset: number. Number of claims to skip.

GET /works/:id

Returns a single signed verifiable work claim by its Id.

For simplicity, this endpoint adds a .anchor in the response, which is not a real part of the claim, but provides valuable information such as the ID of the transaction in which this claim has been anchored, the IPFS directory hash in which it can be found, etc.

A 404 error is returned if the claim isn't found in this Node's database. This doesn't strictly mean the claim does not exist in the Network — it just doesn't exist in this Node.

POST /works

Publish a signed verifiable work claim.

This endpoint is async and returns an ACK, unless an immediate error can be detected (e.g., a malformed claim). There is no guarantee that the work has actually been processed, sent to IPFS and anchored. To confirm that, you'll need to GET /works/:id and check the .anchor attribute.

This endpoint expects a fully constructed signed verifiable claim — with the correct '@context', .id, .issuer, .issuanceDate, .type, and sec:proof. See Building Claims for information on how to correctly create these attributes.

POST /files

Takes a multipart file upload. Currently only allows 1 file to be uploaded at a time and accepts 1 field which is the file to upload.

Returns an array with an object containing the hash and the archive URL of the file.


    hash: "QmS1s76raH43mLT3dSsMt7Nev1t9bM33GTFTZ9foXJV4ZT",
    archiveUrl: ""

Building Claims

A Claim is a signed verifiable claim that holds arbitrary information and allows the network to verify that the claim:

  • has actually been created by a specific person,
  • has not been modified since its creation, and
  • contains a special field type which will allow more features in the future.

For more information about claims and their structure, please see:

Verifying the Claim is on Bitcoin's Blockchain

Once node receives a claim, it stores the claim with some metadata including the following:

  • The highest block read at the time node stores the claim
  • Placeholders for the actual block that was mined including the claim

This allows the node application to track whether or not the claim actually has been successfully saved to the Bitcoin blockchain. There is a configuration value, maximumTransactionAgeInBlocks, that determines how far ahead the blockchain will grow before resubmitting the claim. Comparing this value against the delta between the highest block read and the block read at the time of claim creation will determine whether node resubmits the claim. JS

All the claim logic is abstracted away in JS, so if you are working with JavaScript or TypeScript you can simply use the library:

import { configureCreateVerifiableClaim, createIssuerFromPrivateKey, getVerifiableClaimSigner } from ''

const { configureSignVerifiableClaim } = getVerifiableClaimSigner()

const issuerPrivateKey = 'LWgo1jraJrCB2QT64UVgRemepsNopBF3eJaYMPYVTxpEoFx7sSzCb1QysHeJkH2fnGFgHirgVR35Hz5A1PpXuH6' 
const issuer = createIssuerFromPrivateKey(issuerPrivateKey)

const createVerifiableWorkClaim = configureCreateVerifiableClaim({ issuer })
const signVerifiableClaim = configureSignVerifiableClaim({ privateKey: issuerPrivateKey })

const workClaim = {
  name: 'The Raven',
  author: 'Edgar Allan Poe',
  tags: 'poem',
  dateCreated: '',
  datePublished: '1845-01-29T03:00:00.000Z',
  archiveUrl: '',
  hash: '<hash of content>',

const unsignedVerifiableClaim = await createVerifiableWorkClaim(workClaim)
const signedWorkClaim = await signVerifiableClaim(unsignedVerifiableClaim)

You can find more examples on how to build and publish claims in the integration tests in tests/API/integration/PostWork.test.



Run npm run build to compile the source. This will run TypeScript on the source files and place the output in dist/ts, and will then run Babel and place the output in dist/babel.

Currently, we're only using Babel to support absolute import paths.

During development, you can also run npm run watch to automatically watch for file changes, build the changed files and restart the application on the fly.


Unit and integration tests are located in this repo. You can run both with npm test or separately with npm run test:unit and npm run test:integration.

The integration tests run in isolated instances of the app and database.

Functional tests are run as follows:

  $ docker-compose build
  $ docker-compose up
  $ docker-compose exec poet-node npm run test:functional


Coverage is generated with Istanbul. A more complete report can be generated by running npm run coverage, which will run npm run coverage:unit and npm run coverage:integration together. You may also execute these commands separately.

Note: We are using our own forks of nyc and istanbul-lib-instrument in order to add better support for TypeScript. We intend to contribute our forks back to nyc and istanbul-lib-instrument in order to make our solution available to the entire community. You can follow the issues in this PR, and check the new PRs for istanbul-lib-instrument.





{{o.pubDate | formatDate}}


{{parseInt(o.replyCount) | bigNumberTransform}}
{{parseInt(o.viewCount) | bigNumberTransform}}
{{o.pubDate | formatDate}}


{{parseInt(o.replyCount) | bigNumberTransform}}
{{parseInt(o.viewCount) | bigNumberTransform}}
handlebars 安全漏洞
handlebars是一款语义化的Web模板系统。 handlebars 4.7.7之前版本存在安全漏洞,该漏洞源于当选择某些编译选项来编译来自不可信源的模板时,容易受到原型污染的影响。
CVE-2021-23383 MPS-2021-6180
2022-08-08 20:21
handlebars 存在MAID漏洞
handlebars 是 Mustache 模板语言的扩展。此软件包的受影响版本容易受到原型污染。
2022-08-08 20:21
lodash 存在拒绝服务漏洞
lodash 是一个现代 JavaScript 实用程序库,提供模块化、性能和附加功能。此软件包的受影响版本容易通过 setWith 和 set 函数受到原型污染。
2022-08-08 20:21
marked 存在拒绝服务漏洞
标记是一个低级编译器,用于解析降价而不需要长时间缓存或阻塞。此软件包的受影响版本容易受到正则表达式拒绝服务 (ReDoS) 的攻击。
2022-08-08 20:21
mongodb 存在拒绝服务漏洞
mongodb 是 Node.js 的官方 MongoDB 驱动程序。此软件包的受影响版本容易受到拒绝服务 (DoS) 的攻击。
2022-08-08 20:21
Medialize URI.js 安全漏洞
Medialize URI.js是Medialize团队的一款基于Javascript的可用于高效拼接URL的代码库。 GitHub存储库 1.19.10之前版本的 medialize/uri.js 存在安全漏洞,该漏洞源于medialize/uri.js 中打开重定向。
CVE-2022-0868 MPS-2022-5797
2022-08-08 20:21
npm node-fetch 安全漏洞
node-fetch 2.6.1和3.0.0-beta版本中存在安全漏洞。该漏洞源于内容大小超过限制时,将永远不会抛出FetchError。
CVE-2020-15168 MPS-2020-12719
2022-08-08 20:21
url-parse 安全漏洞
Arnout Kazemier url-parse是美国Arnout Kazemiere(Arnout Kazemier)个人开发者的一个应用软件。提供url解析。 url-parse before 1.5.0 版本存在安全漏洞,该漏洞源于错误处理了反斜杠的某些用法,例如http: /,并将URI解释为相对路径。
CVE-2021-27515 MPS-2021-2265
2022-08-08 20:21
Digital Bazaar Forge 输入验证错误漏洞
Digital Bazaar Forge是美国Digital Bazaar公司的一个 Tls 在 Javascript 中的本机实现以及用于编写基于加密和网络密集型 Web 应用程序的开源工具。 Digital Bazaar Forge 中存在输入验证错误漏洞,该漏洞源于产品允许URL重定向到不受信任的站点。
CVE-2022-0122 MPS-2022-0421
2022-08-08 20:21
semver-regex 存在不正确的正则表达式漏洞
semver-regex 是用于匹配 semver 版本的正则表达式 此软件包的受影响版本容易受到正则表达式拒绝服务 (ReDoS) 的攻击。
2022-08-08 20:21
node-forge 输入验证错误漏洞
node-forge是一个应用软件。一个用于 node-forge 的 WebJar。 所有版本的node-forge软件包都易于通过setPath函数受到原型污染。
CVE-2020-7720 MPS-2020-12281
2022-08-08 20:21
Semantic release 安全漏洞
Semantic release是Semantic release团队的一个基于Js的版本管理和软件包发布工具。 npm semantic-release 17.2.3之前版本存在安全漏洞,该漏洞源于如果包含在URL中被编码的字符,就可能意外地泄露出来。
CVE-2020-26226 MPS-2020-16693
2022-08-08 20:21
Medialize URI.js 输入验证错误漏洞
Medialize URI.js是Medialize团队的一款基于Javascript的可用于高效拼接URL的代码库。 URI.js 存在输入验证错误漏洞,该漏洞源于允许通过使用反斜杠(``)字符后跟一个at(`@`)字符来欺骗主机名。 如果在安全决策中使用了主机名,则该决策可能不正确。 根据库的使用情况和攻击者的意图,影响可能包括允许/阻止列表绕过,开放重定向或其他不良行为。
CVE-2020-26291 MPS-2020-18062
2022-08-08 20:21
Indutny Elliptic 加密问题漏洞
Indutny Elliptic是Indutny个人开发者的一个基于Javascript为应用提供快速椭圆曲线加密的代码库。 Indutny Elliptic 存在安全漏洞,该漏洞源于没有检查来确认公钥。
CVE-2020-28498 MPS-2021-1176
2022-08-08 20:21
NPM url-parse 安全漏洞
Url-Parse是一个跨 Node.js 和浏览器环境无缝工作的小型 Url 解析器。 NPM url-parse 存在安全漏洞,该漏洞源于在1.5.6之前的NPM url-parse中,通过用户控制的密钥绕过授权。
CVE-2022-0512 MPS-2022-3327
2022-08-08 20:21
npm CLI 后置链接漏洞
6.13.3 之前的 npm CLI 版本容易受到任意文件写入的攻击。软件包可以在安装时通过 bin 字段创建指向 node_modules 文件夹之外的文件的符号链接。 package.json bin 字段中正确构造的条目将允许包发布者在安装包时创建指向用户系统上任意文件的符号链接。通过安装脚本仍然可以实现此行为。此漏洞绕过使用 --ignore-scripts 安装选项的用户。
CVE-2019-16775 MPS-2019-16248
2022-08-08 20:21
Ajv 输入验证错误漏洞
Ajv 6.12.2版本中的ajv.validate()函数中存在输入验证错误漏洞。攻击者可利用该漏洞执行代码或造成拒绝服务。
CVE-2020-15366 MPS-2020-10525
2022-08-08 20:21
Chris Brody xmldom 安全漏洞
Chris Brody xmldom是 (Chris Brody)开源的一个应用软件。W3C DOM的JavaScript实现,用于Node.js,Rhino和浏览器。 xmldom 0.4.0及更早版本存在安全漏洞,该漏洞源于没有正确地保留系统标识符、fis或名称空间。
CVE-2021-21366 MPS-2021-3069
2022-08-08 20:21
nodejs 资源管理错误漏洞
nodejs是是一个基于ChromeV8引擎的JavaScript运行环境通过对Chromev8引擎进行了封装以及使用事件驱动和非阻塞IO的应用让Javascript开发高性能的后台应用成为了可能。 nodejs-glob-parent 存在安全漏洞,该漏洞源于正则表达式拒绝服务。
CVE-2020-28469 MPS-2021-7827
2022-08-08 20:21
semver-regex 存在拒绝服务漏洞
semver-regex 是用于匹配 semver 版本的正则表达式。此软件包的受影响版本容易受到正则表达式拒绝服务 (ReDoS) 的攻击。
2022-08-08 20:21
0 评论
0 收藏