"[JUGGLE](https://www.juggle.jp/)" , a secure file-sharing service using the Symbol blockchain developed by [Opening Line, Inc.](https://www.opening-line.co.jp) has been equipped as one of the solutions that make up ["AIR-Plate"](https://air-plate.jp/), has been equipped as one of the solutions that make up [Azusa institute of research](https://azs-air.co.jp/). AIR-Plate is a Building Information Modelling-Facility Management system designed to improve the efficiency of decision-making and management related to the operation and maintenance of facilities.


## Enables secure and easy file sharing

With the following features, JUGGLE enables **secure and easy file sharing**.
* Automatic encryption of both passwords and files
* Existing sharing tools can be used without modification
* Accident prevention (disable sharing function)
* Traceability (confirmation of opening and sharing)
* Can only be opened on specific devices

While retaining the simplicity and convenience of email, blockchain technology enables secure file sharing without the worry of passwords.

JUGGLE is not only designed for file sharing, it can also be customised to work with other systems to share files securely between users. In AIR-Plate, to protect and share classified information in a securely stored database. 


#### ※patent pending　[特願：2021-145814](https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2022-124446/333F01A6F3FB93E25868C99B83660D51BFEA268E86EBCCC86FF33A69522227BA/11/ja)


### Without being aware of crypto assets, users can use public blockchains
JUGGLE uses the "aggregate bonded transaction" feature of the Symbol blockchain when it uses the blockchain.
※[Aggregate bonded transaction](https://docs.symbol.dev/concepts/aggregate-transaction.html) functionality: the ability to write multiple transactions to the blockchain simultaneously.

![JUGGLE-1ENG.png](/uploads/JUGGLE_1_ENG_6e5d26bdc3.png)

This feature ensures that all transaction costs incurred by JUGGLE are covered by Opening Line, Inc.

This allows JUGGLE users to use the public blockchain without holding crypto assets.

This means that companies can use public blockchains without having to worry about the accounting and tax issues of crypto assets, which can be a concern when adopting public blockchains in their business.

### Related site/articles
[Opening Line, Inc.](https://www.opening-line.co.jp)
[JUGGLE](https://www.juggle.jp/)
[Azusa institute of research](https://azs-air.co.jp/)
[BITTIMES](https://bittimes.net/news/145808.html)
[BITTIMES](https://bittimes.net/news/146405.html)
[PRtimes](https://prtimes.jp/main/html/rd/p/000000011.000097604.html)

## Q&A with Opening Line, Inc.
-Q1. Currently, digital data sharing has become a service of great interest in the world of digital transformation and the spread of remote working. What are JUGGLE’s strengths compared to other cloud services?

Unlike other cloud-based file-sharing services, JUGGLE sharing files in encrypted form. Therefore, even if the server used by JUGGLE is hacked, the files themselves remain kept safe, making it more secure than other services.

![JUGGLE-2ENG.png](/uploads/JUGGLE_2_ENG_a80688da42.png)

-Q2. Through this integration with the AIR-Plate service. We assume that other companies will be interested in JUGGLE. Please tell us about any difficulties that Opening Line, Inc. encountered in integrating the system and any advantages of JUGGLE, such as its versatility and high affinity.

JUGGLE has been developed with the aim to go beyond a simple file sharing system and to integrate with other systems. Since the AIR-Plate development phase, we have been working on AIR-Plate integration, use cases and customisation. JUGGLE’s strength is that it can be customised and integrated into its own existing systems.


-Q3. Could you please tell us how you came to choose Symbol as the blockchain technology for JUGGLE?

As we mentioned above, Symbol’s ability to aggregate multiple transactions into one, the ‘aggregate transaction’, allowing users to benefit from the public blockchain without holding crypto assets, has been an advantage in its adoption.

-Q4. We’d like to ask you about your outlook for the future?

We have received feedback from customers who have been using the service since the early days and after reviewing the service, finally we are ready to sell it widely and hope that many people will use the standard version of JUGGLE in the future. We will also be integrating JUGGLE into the services which customers use, providing a safe and secure file sharing environment for many people.

JUGGLE has been integrated as one of the component solutions of AIR-Plate, a BIM-FM solution developed by Azusa institute of research.

large_JUGGLE.jpg

medium_JUGGLE.jpg

small_JUGGLE.jpg

thumbnail_JUGGLE.jpg

JUGGLE.jpg

[Opening Line](https://www.opening-line.co.jp)が開発するSymbolブロックチェーンを活用したファイルセキュリティシステム[「JUGGLE」](https://www.juggle.jp/)が、[梓総合研究所](https://azs-air.co.jp/)の開発する施設運営DXを推し進める[「AIR-Plate」](https://air-plate.jp/)を構成するひとつのソリューションとして搭載されました。「AIR-Plate」は施設総合管理システムとして開発され建物の運用・保守に関する意思決定や作業を効率化を実現するシステムです。

## 安心安全なファイル共有を実現するJUGGLE

JUGGLEは下記の特徴を兼ね備え、**安心で簡単なファイル共有**を実現しています。

* パスワードもファイルも自動で暗号化されるシンプルな操作性
* 社内の共有かツールはそのまま使用可能
* 誤送信対策（共有無効化機能）
* トレーサビリティ（開封・共有確認）
* 特定の端末でしか開けない

JUGGLEはEmailの手軽さや便利さをそのままにして、ブロックチェーン技術を利用することでパスワードを意識せずに、安心・安全にファイルを共有することを実現できます。

JUGGLEは単にファイル共有のみならず、他のシステムと連携して安全にデータを共有するカスタマイズも可能です。AIR-Plate上では、データベースに蓄積されたデータを安全かつ簡単に共有するために活用されています。

#### ※特許出願中　[特願：2021-145814](https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2022-124446/333F01A6F3FB93E25868C99B83660D51BFEA268E86EBCCC86FF33A69522227BA/11/ja)

#### 暗号資産を意識することなくパブリックブロックチェーンの利用が可能
JUGGLEでは、ブロックチェーンに書き込む際に、Symbolブロックチェーンに標準装備されているアグリゲートボンデッドトランザクション機能を利用しています。
※ [アグリゲートボンデッドトランザクション機能](https://docs.symbol.dev/ja/concepts/aggregate-transaction.html):複数のトランザクションをまとめて同時にブロックチェーンに書き込む機能

![JUGGLE-1.png](/uploads/JUGGLE_1_559191c090.png)


この機能を利用することで、JUGGLEで発生するすべてのトランザクション手数料をOpening Lineが負担するようにしています。
JUGGLEでは、利用者は、暗号資産の保持する必要はなく、パブリックブロックチェーンをご利用いただくことができます。

そのため、企業でパブリックブロックチェーンを採用するときに懸念事項となる暗号資産の会計や税務上の課題を意識することなく安心してご利用いただくことが可能です。

### 関連サイト/記事
[株式会社Opening Line](https://www.opening-line.co.jp)
[JUGGLE](https://www.juggle.jp)
[梓総合研究所](https://azs-air.co.jp/)
[BITTIMES](https://bittimes.net/news/145808.html)
[BITTIMES](https://bittimes.net/news/146405.html)
[PRtimes](https://prtimes.jp/main/html/rd/p/000000011.000097604.html)

## 株式会社Opening LineへのQ&A

-Q1. DXが進みテレワークが普及した現在でデジタルデータの受け渡しは非常に関心が高いサービスになっていると存じます。他クラウドサービスなどと比べて「JUGGLE」の強みはどのようなところでしょうか。

JUGGLEは他のクラウド上でファイル共有するサービスと違い、ファイル自体も暗号化した状態でやりとりしています。そのため、万一JUGGLEで利用しているサーバをハッキングされてもファイル自体は保全されるため他のサービスと比べてもセキュリティが高いです。

![JUGGLE-2.png](/uploads/JUGGLE_2_cb8733d6bc.png)


-Q2. 今回AIR-Plateサービスへ搭載され、興味を持たれる企業様も多く出てくると存じます。導入にあたって苦労した部分や「JUGGLE」のもつ汎用性・親和性の高さなどのアドバンテージなどがあれば教えてください。

JUGGLEは単なるファイル共有システムを超えて、他のシステムとも連携できることを目標にこれまで開発してきました。AIR-Plateへの搭載に向けてはAIR-Plateの開発段階から参画させて頂き、ユースケースなどをヒアリングしてカスタマイズ開発を行ってきました。カスタマイズして自社のシステムに組み込めるようにしているのが強みとなります。

-Q3. 「JUGGLE」で利用するブロックチェーン技術としてSymbolを採用するに至った経緯などあれば教えてください。

先に記載の通り、Symbolには複数のトランザクションを1つにまとめて処理するボンデッドトランザクション機能があり、これを利用することで利用者が暗号資産を持たなくてもパブリックブロックチェーンのメリットを受けることができるのが採用に至ったメリットです。

-Q4. 今後の展望などがあればお聞かせください。

初期から導入頂いているお客様の声も受け、サービスの見直しなども行いようやく広く販売できる準備が整って参りました、これから標準版のJUGGLEも多くの人に利用頂ければと考えております。また自社のサービスへの組み込みなども行い、多くの人に安心・安全なファイル共有環境を提供してまいります。

「JUGGLE」が梓総合研究所が開発する施設運営のDXを推し進める画期的なBIM-FMソリューション「AIR-Plate」の構成ソリューションの1つとして搭載されました。

安心・簡単なファイル共有を可能に「JUGGLE」

"[JUGGLE](https://www.juggle.jp/)" 를 구성하는 솔루션 중 하나로  [Opening Line, Inc.](https://www.opening-line.co.jp) 가 개발한 Symbol blockchain 을 이용한 안전한 파일 공유 서비스인  ["AIR-Plate"](https://air-plate.jp/)가 [Azusa institute of research](https://azs-air.co.jp/),  ["AIR-Plate"](https://air-plate.jp/) 는 시설물의 운영 및 유지 보수에 관한 의사 결정 및 관리의 효율성을 향상시키기 위해 설계된 빌딩 정보 모델링-시설물 관리 시스템입니다.


## 안전하고 간편한 파일 공유 지원

다음과 같은 기능을 통해 JUGGLE 은 **안전하고 간편한 파일 공유** 를 지원합니다.
* 비밀번호와 파일 모두 자동 암호화
* 기존 공유 도구를 수정 없이 사용 가능
* 사고 예방(공유 기능 비활성화)
* 추적성(개봉 및 공유 확인)
* 특정 기기에서만 열 수 있음

이메일의 간편함과 편리함은 그대로 유지하면서 블록체인 기술을 통해 비밀번호 걱정 없이 안전하게 파일을 공유할 수 있습니다.

JUGGLE은 파일 공유를 위해 설계되었을 뿐만 아니라 다른 시스템과 함께 작동하도록 사용자 지정하여 사용자 간에 파일을 안전하게 공유할 수도 있습니다. AIR-Plate에서는 기밀 정보를 안전하게 저장된 데이터베이스에서 보호하고 공유할 수 있습니다. 


#### ※patent pending　[特願：2021-145814](https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2022-124446/333F01A6F3FB93E25868C99B83660D51BFEA268E86EBCCC86FF33A69522227BA/11/ja)


### 사용자는 암호화폐 자산에 대한 지식 없이도 퍼블릭 블록체인을 사용할 수 있습니다.
JUGGLE 은 블록체인을 사용할 때 Symbol blockchain 의 "aggregate bonded transaction" 기능을 사용합니다.
※[Aggregate bonded transaction](https://docs.symbol.dev/concepts/aggregate-transaction.html) functionality: the ability to write multiple transactions to the blockchain simultaneously.

![JUGGLE-1ENG.png](/uploads/JUGGLE_1_ENG_6e5d26bdc3.png)

이 기능은 JUGGLE 에서 발생하는 모든 거래 비용을 Opening Line, Inc. 가 부담하도록 보장합니다.

이를 통해 JUGGLE 사용자는 암호화폐 자산을 보유하지 않고도 퍼블릭 블록체인을 사용할 수 있습니다.

이는 기업들이 퍼블릭 블록체인을 비즈니스에 도입할 때 우려할 수 있는 암호화폐 자산의 회계 및 세금 문제에 대해 걱정할 필요 없이 퍼블릭 블록체인을 사용할 수 있다는 의미입니다.

### Related site/articles
[Opening Line, Inc.](https://www.opening-line.co.jp)
[JUGGLE](https://www.juggle.jp/)
[Azusa institute of research](https://azs-air.co.jp/)
[BITTIMES](https://bittimes.net/news/145808.html)
[BITTIMES](https://bittimes.net/news/146405.html)
[PRtimes](https://prtimes.jp/main/html/rd/p/000000011.000097604.html)

## Q&A with Opening Line, Inc.
-Q1. 최근 디지털 데이터 공유는 디지털 트랜스포메이션과 재택근무 확산에 따라 큰 관심을 받고 있는 서비스입니다. 다른 클라우드 서비스와 비교했을 때 JUGGLE 의 강점은 무엇인가요?

다른 클라우드 기반 파일 공유 서비스와 달리 JUGGLE은 파일을 암호화된 형태로 공유합니다. 따라서 JUGGLE에서 사용하는 서버가 해킹을 당하더라도 파일 자체는 안전하게 보관되어 다른 서비스보다 보안성이 뛰어납니다.

![JUGGLE-2ENG.png](/uploads/JUGGLE_2_ENG_a80688da42.png)

-Q2. AIR-Plate 서비스와의 통합을 통해. 다른 기업들도 JUGGLE 에 관심을 가질 것으로 생각됩니다. 시스템 연동 과정에서 Opening Line, Inc. 가 겪은 어려움과 JUGGLE 의 범용성, 높은 친화력 등 장점에 대해 말씀해 주세요.

JUGGLE은 단순한 파일 공유 시스템을 넘어 다른 시스템과 통합하는 것을 목표로 개발되었습니다. AIR-Plate 개발 단계부터 AIR-Plate 통합, 사용 사례 및 커스터마이징을 위해 노력해 왔습니다. 저글의 강점은 기존 시스템에 맞게 커스터마이징하고 통합할 수 있다는 점입니다.


-Q3. JUGGLE 의 블록체인 기술로  Symbol 을 선택하게 된 계기를 말씀해 주시겠어요?

앞서 언급했듯이 Symbol 은 여러 트랜잭션을 하나로 통합하는 '총합 트랜잭션' 기능을 통해 사용자가 암호화폐 자산을 보유하지 않고도 퍼블릭 블록체인의 이점을 누릴 수 있다는 점이 채택에 유리하게 작용했습니다.

-Q4. 앞으로의 전망에 대해 궁금합니다.

초기부터 서비스를 이용하고 계신 고객님들의 피드백을 받아 검토를 거쳐 드디어 널리 판매할 수 있게 되었으며, 앞으로 많은 분들이 표준 버전의 JUGGLE을 이용해 주셨으면 합니다. 또한 고객이 사용하는 서비스에 JUGGLE을 통합하여 많은 사람들에게 안전한 파일 공유 환경을 제공하겠습니다.

안전하고 간편한 파일 공유 'Juggle' 지원

"[JUGGLE](https://www.juggle.jp/)" , 使用Symbol区块链开发的安全文件分享服务 [Opening Line, Inc.](https://www.opening-line.co.jp) 作为其中一个组成部分，已经配备了一个解决方案 ["AIR-Plate"](https://air-plate.jp/), 已经配备为其中一个组成解决方案的服务 [Azusa institute of research](https://azs-air.co.jp/). AIR-Plate 是一个建筑信息模型-设施管理系统，旨在提高与设施运营和维护相关的决策和管理效率。


## 提供安全且方便的文件分享功能

凭藉以下功能，JUGGLE实现了安全且方便的文件分享。
* 自动加密密码和文件
* 可以在不修改的情况下使用现有的分享工具
* 预防意外（禁用分享功能）
* 追踪功能（确认开启和分享）
* 只能在特定设备上开启

在保留电子邮件的简单性和便利性的同时，区块链技术实现了安全的文件分享，无需担心密码的问题。

JUGGLE 不仅仅是为了文件分享而设计的，它还可以根据需要定制以与其他系统配合，实现用户之间的安全文件分享。在 AIR-Plate 中，可以使用 JUGGLE 来保护和分享安全存储的敏感信息。


#### ※专利申请中　[临时专利申请：2021-145814](https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2022-124446/333F01A6F3FB93E25868C99B83660D51BFEA268E86EBCCC86FF33A69522227BA/11/ja)


### 使用公共区块链的用户可以在不了解加密资产的情况下使用。
JUGGLE 在使用 Symbol 区块链时使用了“聚合绑定交易”功能。
※[聚合保税交易](https://docs.symbol.dev/concepts/aggregate-transaction.html) 功能：同时将多个交易写入区块链的能力

![JUGGLE-1ENG.png](/uploads/JUGGLE_1_ENG_6e5d26bdc3.png)

该功能确保了 JUGGLE 所产生的所有交易成本由 Opening Line 公司承担。

这使得 JUGGLE 的用户可以在不持有加密资产的情况下使用公共区块链。

这意味着企业可以在采用公共区块链时，无需担心加密资产的会计和税务问题。对于企业在业务中采用公共区块链时，这可能是一个令人担忧的问题。

### 相关网站/文章
[Opening Line, Inc.](https://www.opening-line.co.jp)
[JUGGLE](https://www.juggle.jp/)
[Azusa institute of research](https://azs-air.co.jp/)
[BITTIMES](https://bittimes.net/news/145808.html)
[BITTIMES](https://bittimes.net/news/146405.html)
[PRtimes](https://prtimes.jp/main/html/rd/p/000000011.000097604.html)

## Opening Line公司问答（Q&A）
-Q1. 目前，数字资料分享已成为数位转型和远程工作普及的重要服务。相较于其他云端服务，JUGGLE有哪些优势呢？

与其他基于云端的文件分享服务不同，JUGGLE以加密形式进行文件分享。因此，即使JUGGLE使用的伺服器遭受入侵，文件本身仍然保持安全，使其比其他服务更安全可靠。

![JUGGLE-2ENG.png](/uploads/JUGGLE_2_ENG_a80688da42.png)

-Q2. 透过与AIR-Plate服务的整合，我们预计其他公司也会对JUGGLE产生兴趣。请告诉我们Opening Line公司在整合系统过程中遇到的困难以及JUGGLE的优势，例如其多功能性和高亲和力。

JUGGLE的开发目标不仅仅是成为一个简单的文件分享系统，还要与其他系统进行整合。从AIR-Plate的开发阶段开始，我们一直在致力于AIR-Plate的整合、使用案例和定制化。JUGGLE的优势在于它可以根据需要进行定制和整合到现有的系统中。


-Q3. 您能告诉我们您是如何选择 Symbol 作为 JUGGLE 的区块链技术的吗？

正如我们之前提到的，Symbol区块链具有将多个交易聚合成一个的功能，称为“聚合交易”，使用户能够在不持有加密资产的情况下从公共区块链中受益，这在Symbol的采用中是一个优势。

-Q4. 我们想问一下您对未来的展望？

我们收到了早期使用该服务的客户的反馈，经过审查后，我们终于准备广泛销售该服务，希望未来有很多人使用JUGGLE的标准版。我们还将把JUGGLE整合到客户使用的服务中，为许多人提供安全可靠的文件分享环境。

JUGGLE 已集成为 AIR-Plate 的组件解决方案之一，AIR-Plate 是 Azusa 研究所开发的 BIM-FM 解决方案。

”JUGGLE“ 提供安全且方便的文件分享服务

"[JUGGLE](https://www.juggle.jp/)" , 使用Symbol區塊鏈開發的安全文件分享服務 [Opening Line, Inc.](https://www.opening-line.co.jp) 作為其中一個組成部分，已經配備了一個解決方案 ["AIR-Plate"](https://air-plate.jp/), 已經配備為其中一個組成解決方案的服務 [Azusa institute of research](https://azs-air.co.jp/). AIR-Plate 是一個建築信息模型-設施管理系統，旨在提高與設施運營和維護相關的決策和管理效率。


## 提供安全且方便的文件分享功能

憑藉以下功能，JUGGLE實現了安全且方便的文件分享。
* 自動加密密碼和文件
* 可以在不修改的情況下使用現有的分享工具
* 預防意外（禁用分享功能）
* 追蹤功能（確認開啟和分享）
* 只能在特定設備上開啟

在保留電子郵件的簡單性和便利性的同時，區塊鏈技術實現了安全的文件分享，無需擔心密碼的問題。

JUGGLE 不僅僅是為了文件分享而設計的，它還可以根據需要定制以與其他系統配合，實現用戶之間的安全文件分享。在 AIR-Plate 中，可以使用 JUGGLE 來保護和分享安全存儲的敏感信息。


#### ※專利申請中　[臨時專利申請：2021-145814](https://www.j-platpat.inpit.go.jp/c1800/PU/JP-2022-124446/333F01A6F3FB93E25868C99B83660D51BFEA268E86EBCCC86FF33A69522227BA/11/ja)


### 使用公共區塊鏈的用戶可以在不了解加密資產的情況下使用。
JUGGLE 在使用 Symbol 區塊鏈時使用了「聚合綁定交易」功能。
※[聚合保稅交易](https://docs.symbol.dev/concepts/aggregate-transaction.html) 功能：同時將多個交易寫入區塊鏈的能力

![JUGGLE-1ENG.png](/uploads/JUGGLE_1_ENG_6e5d26bdc3.png)

該功能確保了 JUGGLE 所產生的所有交易成本由 Opening Line 公司承擔。

這使得 JUGGLE 的用戶可以在不持有加密資產的情況下使用公共區塊鏈。

這意味著企業可以在採用公共區塊鏈時，無需擔心加密資產的會計和稅務問題。對於企業在業務中採用公共區塊鏈時，這可能是一個令人擔憂的問題。

### 相關網站/文章
[Opening Line, Inc.](https://www.opening-line.co.jp)
[JUGGLE](https://www.juggle.jp/)
[Azusa institute of research](https://azs-air.co.jp/)
[BITTIMES](https://bittimes.net/news/145808.html)
[BITTIMES](https://bittimes.net/news/146405.html)
[PRtimes](https://prtimes.jp/main/html/rd/p/000000011.000097604.html)

## Opening Line公司問答（Q&A）
-Q1. 目前，數字資料分享已成為數位轉型和遠程工作普及的重要服務。相較於其他雲端服務，JUGGLE有哪些優勢呢？

與其他基於雲端的文件分享服務不同，JUGGLE以加密形式進行文件分享。因此，即使JUGGLE使用的伺服器遭受入侵，文件本身仍然保持安全，使其比其他服務更安全可靠。

![JUGGLE-2ENG.png](/uploads/JUGGLE_2_ENG_a80688da42.png)

-Q2. 透過與AIR-Plate服務的整合，我們預計其他公司也會對JUGGLE產生興趣。請告訴我們Opening Line公司在整合系統過程中遇到的困難以及JUGGLE的優勢，例如其多功能性和高親和力。

JUGGLE的開發目標不僅僅是成為一個簡單的文件分享系統，還要與其他系統進行整合。從AIR-Plate的開發階段開始，我們一直在致力於AIR-Plate的整合、使用案例和定制化。JUGGLE的優勢在於它可以根據需要進行定制和整合到現有的系統中。


-Q3. 您能告訴我們您是如何選擇 Symbol 作為 JUGGLE 的區塊鏈技術的嗎？

正如我們之前提到的，Symbol區塊鏈具有將多個交易聚合成一個的功能，稱為「聚合交易」，使用戶能夠在不持有加密資產的情況下從公共區塊鏈中受益，這在Symbol的採用中是一個優勢。

-Q4. 我們想問一下您對未來的展望？

我們收到了早期使用該服務的客戶的反饋，經過審查後，我們終於準備廣泛銷售該服務，希望未來有很多人使用JUGGLE的標準版。我們還將把JUGGLE整合到客戶使用的服務中，為許多人提供安全可靠的文件分享環境。

JUGGLE 已集成為 AIR-Plate 的組件解決方案之一，AIR-Plate 是 Azusa 研究所開發的 BIM-FM 解決方案。

”JUGGLE“ 提供安全且方便的文件分享服務

Enables secure and easy file sharing "Juggle"

On 18 May 2023, Settler Ltd announced that its portfolio management service, the 'Settler' app, now supports the display of NFTs. At the moment only Ethereum based NFTs can be viewed, other chain based NFTs will be added later. The service provides users with the balance of assets deposited on the exchange and in each non-custodial wallet, as well as their price in Japanese yen, the percentage of each crypto asset on the exchange and blockchain in the portfolio. It also shows assets under staking or lending. Settler's vision is to "create a society where people can keep track of their assets like in a simulation game" and uses exchange APIs and users' wallet addresses to retrieve asset data and daily asset amounts. In terms of security, while the Settler app does store wallet addresses and encrypted API keys, Settler Ltd has a policy of not storing user information that is linked to individuals and takes the protection of users' personal data seriously.

Settler also supports the Symbol/NEM network. By registering addresses, the balance can be shown.

[News]
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000005.000106574.html)

[Other infomation]
[Settler Ltd,](https://settler.cc/)
[Settler app](https://app.settler.cc)

Settler Co., Ltd. announced on May 18, 2023 that it also supports the display of NFTs in the portfolio management service “Settler”.

medium_Settlereyecatch-min.png

small_Settlereyecatch-min.png

thumbnail_Settlereyecatch-min.png

Settlereyecatch-min.png

![Settlereyecatch-min.png](/uploads/Settlereyecatch_min_fb478c5304.png)

株式会社Settlerは2023年5月18日、ポートフォリオ管理サービス「Settler」にてNFTの表示にも対応したことを発表しました。現時点では、Ethereum上のNFTのみが表示可能であり、今後他のNFT対応チェーンも順次追加予定です。同サービスでは、暗号資産取引所やブロックチェーン上にある各暗号資産の数量や日本円建て金額、ポートフォリオ内の割合などを一括で把握することができます。また、ステーキングやレンディング中の資産も表示されます。Settlerは「シミュレーションゲームのようにお金を把握できる社会を実現する」をビジョンに取引所APIとユーザーのウォレットアドレスを使用して資産データを取得し、毎日の資産額の推移も確認できるようにしています。セキュリティ面では、ウォレットアドレスや暗号化されたAPIキーを保持するが利用者様個人とは結びつく情報を持たない方針を採用し、利用者の個人情報保護に真剣に取り組んでいます。  
「Settler」ではSymbol/NEMネットワークにも対応しており、アドレスの登録で残高表示が可能です。

[プレスリリース]
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000005.000106574.html)

[情報]
[株式会社Settler](https://settler.cc/)
[Settlerサ-ビス](https://app.settler.cc)

株式会社Settlerは2023年5月18日、ポートフォリオ管理サービス「Settler」にてNFTの表示にも対応したことを発表しました。

株式会社Settler 暗号資産ポートフォリオサービスSymbol/NEMネットワークに対応

This page is a machine translation of the English text. Please contact [faunsu](https://twitter.com/faunsu19000) or [Symbol Community Web](https://symbol-community.com/ja/community) for language proofreading of articles.
![Settlereyecatch-min.png](/uploads/Settlereyecatch_min_fb478c5304.png)

(주)세틀러는 2023년 5월 18일 포트폴리오 관리 서비스 '세틀러'에서 NFT 표시도 지원한다고 밝혔다. 현재 이더리움의 NFT만 표시할 수 있으며 향후 다른 NFT 호환 체인이 추가될 예정입니다. 이 서비스를 통해 암호화폐 거래소 및 블록체인 상의 암호화폐별 거래량, 엔화 금액, 포트폴리오 비율 등을 파악할 수 있다. 또한 스테이킹 또는 렌딩 중인 자산도 보여준다. Settler의 비전은 "시뮬레이션 게임처럼 돈을 움켜쥘 수 있는 사회를 실현"하는 것입니다. 거래소 API와 사용자의 지갑 주소를 사용하여 자산 데이터를 획득하고 매일 자산 금액의 변화를 확인할 수 있습니다. 증가하다. 보안상 지갑 주소와 암호화된 API 키를 보유하되 개인 사용자와 연결된 정보는 보유하지 않는 정책을 채택하고 있으며, 사용자의 개인정보 보호에 만전을 기하고 있습니다.
"Settler"는 Symbol/NEM 네트워크도 지원하며 주소를 등록하여 잔액을 표시할 수 있습니다.

[보도 자료]
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000005.000106574.html)

[정보]
[株式会社Settler](https://settler.cc/)
[Settler 서비스](https://app.settler.cc)

(주)세틀러는 2023년 5월 18일 포트폴리오 관리 서비스 '세틀러'에서 NFT 표시도 지원한다고 밝혔다.

(주)세틀러, 암호화폐 자산 포트폴리오 서비스 심볼 네트워크 지원

This page is a machine translation of the English text. Please contact [faunsu](https://twitter.com/faunsu19000) or [Symbol Community Web](https://symbol-community.com/ja/community) for language proofreading of articles.
![Settlereyecatch-min.png](/uploads/Settlereyecatch_min_fb478c5304.png)

Settler Ltd. 于 2023 年 5 月 18 日宣布，它也支持在投资组合管理服务“Settler”中展示 NFT。 目前只能展示以太坊上的NFT，未来会增加其他NFT兼容链。 通过这项服务，可以掌握加密资产交易所和区块链上每个加密资产的数量、日元金额、投资组合中的百分比等。它还显示正在质押或借贷的资产。 Settler的愿景是“实现一个像模拟游戏一样可以掌握金钱的社会”，利用交易所API和用户的钱包地址获取资产数据，并可以查看资产数量的日常变化。 增加。 在安全方面，我们采取了保留钱包地址和加密API密钥的政策，但没有与个人用户绑定的信息，并认真致力于保护用户的个人信息。
《Settler》还支持Symbol/NEM 网络，您可以通过注册您的地址来显示您的余额。

[新闻稿]
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000005.000106574.html)

[信息]
[株式会社Settler](https://settler.cc/)
[Settler 服务](https://app.settler.cc)

Settler Co., Ltd. 于 2023 年 5 月 18 日宣布，它也支持在投资组合管理服务“Settler”中展示 NFT。

Settler Co., Ltd. 支持加密资产组合服务 Symbol Network

This page is a machine translation of the English text. Please contact [faunsu](https://twitter.com/faunsu19000) or [Symbol Community Web](https://symbol-community.com/ja/community) for language proofreading of articles.
![Settlereyecatch-min.png](/uploads/Settlereyecatch_min_fb478c5304.png)

Settler Ltd. 於 2023 年 5 月 18 日宣布，它也支持在投資組合管理服務“Settler”中展示 NFT。 目前只能展示以太坊上的NFT，未來會增加其他NFT兼容鏈。 通過這項服務，可以掌握加密資產交易所和區塊鏈上每個加密資產的數量、日元金額、投資組合中的百分比等。它還顯示正在質押或借貸的資產。 Settler的願景是“實現一個像模擬遊戲一樣可以掌握金錢的社會”，利用交易所API和用戶的錢包地址獲取資產數據，並可以查看資產數量的日常變化。 增加。 在安全方面，我們採取了保留錢包地址和加密API密鑰的政策，但沒有與個人用戶綁定的信息，並認真致力於保護用戶的個人信息。
《Settler》還支持Symbol/NEM 網絡，您可以通過註冊您的地址來顯示您的餘額。

[新闻稿]
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000005.000106574.html)

[信息]
[株式会社Settler](https://settler.cc/)
[Settler 服務](https://app.settler.cc)

Settler Co., Ltd. 於 2023 年 5 月 18 日宣布，它也支持在投資組合管理服務“Settler”中展示 NFT。

Settler Ltd, the crypto asset portfolio service provider, now supports Symbol and NEM.

The Open Source Conference is an exhibition providing the latest information on open source.
![OSC.png](/uploads/OSC_2ab00a30f0.png)

 [Open Source Conference 2023 Nagoya](https://event.ospn.jp/osc2023-nagoya/)
*  Date and time: 28 May 2023 11:00 - 16:00(JST)
*  Venue: [中小企業振興会館](https://www.nipc.or.jp/fukiage/) (Nagoya Trade & Industry Centre), 3rd floor, 2nd Fashion Exhibition Hall
*  Admission Fee: Free
 
 [Open Source Conference 2023 Hokkaido](https://event.ospn.jp/osc2023-do/)
*  Date and time: 24 June 2023 10:00 - 16:00(JST)
*  Venue: [札幌市産業振興センター](https://www.sapporosansin.jp) (Sapporo Business Innovation Centre), 2rd floor, Room A
*  Admission Fee: Free

[NEMTUS（NEM+）](https://nemtus.com)(特定非営利活動法人NEM技術普及推進会NEMTUS) is a non-profit organisation that aims to promote and develop NEM and Symbol technology in Japan.

NEMTUS will exhibit at the "Open Source Conference 2023"

large_NEMTUS.PNG

medium_NEMTUS.PNG

small_NEMTUS.PNG

thumbnail_NEMTUS.PNG

NEMTUS.PNG

オープンソースカンファレンスは、オープンソースに関する最新情報の提供を行う展示会です。
![OSC.png](/uploads/OSC_2ab00a30f0.png)

 [Open Source Conference 2023 Nagoya](https://event.ospn.jp/osc2023-nagoya/)
*  日時: 28 May 2023 11:00 - 16:00(JST)
*  会場: [中小企業振興会館](https://www.nipc.or.jp/fukiage/) 3階 第2ファッション展示場
*  入場料: Free
 
 [Open Source Conference 2023 Hokkaido](https://event.ospn.jp/osc2023-do/)
*  日時: 24 June 2023 10:00 - 16:00(JST)
*  会場: [札幌市産業振興センター](https://www.sapporosansin.jp) 2F ルームA
*  入場料: Free

[NEMTUS（NEM+）](https://nemtus.com)(特定非営利活動法人NEM技術普及推進会NEMTUS) は、日本において「NEM（ネム）」と「Symbol（シンボル）」技術の普及や発展を促進するNPO法人です。

NEMTUSがオープンソースの祭典「オープンソースカンファレンス2023」に出展します

开源(Open Source)大会是一个展览会，提供有关开源最新信息的资讯。
![OSC.png](/uploads/OSC_2ab00a30f0.png)

 [2023 年 名古屋开源大会](https://event.ospn.jp/osc2023-nagoya/)
*  日期和时间：2023 年 5 月 28 日 11:00 - 16:00（日本标准时间）
*  场地: [中小企业振兴会馆](https://www.nipc.or.jp/fukiage/)-3楼第2时装展厅
*  入场费：免费
 
 [2023 年 北海道开源大会](https://event.ospn.jp/osc2023-do/)
*  日期和时间：2023 年 6 月 24 日 10:00 - 16:00（日本标准时间）
* 场地: [札幌产业振兴中心](https://www.sapporosansin.jp)-2楼A室
*  入场费：免费

[NEMTUS（NEM+）](https://nemtus.com)(特定非営利活动法人NEM技术普及推进会NEMTUS) 是一个非营利组织，宗旨在日本推广和开发 NEM 和 Symbol 技术。
 

NEMTUS 将参展“Open Source Conference 2023”。

NEMTUS 將在「Open Source Conference 2023」展出。

開源(Open Source)大會是一個展覽會，提供有關開源最新信息的資訊。
![OSC.png](/uploads/OSC_2ab00a30f0.png)

 [2023 年 名古屋開源大會](https://event.ospn.jp/osc2023-nagoya/)
*  日期和時間：2023 年 5 月 28 日 11:00 - 16:00（日本標準時間）
*  場地: [中小企業振興会館](https://www.nipc.or.jp/fukiage/)-3樓第2時裝展廳
*  入場費：免費
 
 [2023 年 北海道開源大會](https://event.ospn.jp/osc2023-do/)
*  日期和時間：2023 年 6 月 24 日 10:00 - 16:00（日本標準時間）
* 場地: [札幌產業振興中心](https://www.sapporosansin.jp)-2樓A室
*  入場費：免費

[NEMTUS（NEM+）](https://nemtus.com)(特定非営利活動法人NEM技術普及推進会NEMTUS) 是一個非營利組織，宗旨在日本推廣和開發 NEM 和 Symbol 技術。

NEMTUS 將參展「Open Source Conference 2023」。

Open Source Conference 는 오픈소스에 대한 최신 정보를 제공하는 전시회입니다.
![OSC.png](/uploads/OSC_2ab00a30f0.png)

 [Open Source Conference 2023 Nagoya](https://event.ospn.jp/osc2023-nagoya/)
*  날짜와 시간: 28 May 2023 11:00 - 16:00(JST)
*  장소: [中小企業振興会館](https://www.nipc.or.jp/fukiage/) (Nagoya 무역 및 산업 센터), 3층, 2위 Fashion Exhibition Hall
*  입장료: Free
 
 [Open Source Conference 2023 Hokkaido](https://event.ospn.jp/osc2023-do/)
*  날짜와 시간: 24 June 2023 10:00 - 16:00(JST)
*  장소: [札幌市産業振興センター](https://www.sapporosansin.jp) (Sapporo 비즈니스 이노베이션 센터), 층, 객실 A
*  입장료: Free

[NEMTUS（NEM+）](https://nemtus.com)(特定非営利活動法人NEM技術普及推進会NEMTUS) 은 일본에서 NEM 과 Symbol 기술을 홍보하고 개발하는 것을 목표로 하는 비영리 단체입니다.

NEMTUS 가 "Open Source Conference 2023" 에 참가합니다

The Technical Bookstore is an event where books and other publications on IT, science and other technologies are distributed and sold, and the Technical Bookstore 14 will take place from 20 May 2023.

[Technical Bookstore 14 Official website](https://techbookfest.org) 

* Online 
〈Dates〉20 May 2023 10:00(JST)~4 June 23:59(JST) 
〈Venue〉[Technical Bookstore Online Market](https://techbookfest.org/market)  

* Offline 
〈Date〉21 May 2023 11:00~17:00(JST)
〈Venue〉[Ikebukuro Sunshine City](https://sunshinecity.jp/en/) Exhibition Hall D (Bunka Kaikan Building 2F)

NEMTUS(特定非営利活動法人NEM技術普及推進会NEMTUS) is a non-profit organisation that aims to promote and develop NEM and Symbol technology in Japan.
![NEMTUS.PNG](/uploads/NEMTUS_acd681ed60.PNG)

The books that NEMTUS will be exhibiting at this Technical Bookstore 14 are

1. "Quick Learning Symbol" Javascript edition
2. "Quick Learning Symbol" C# Edition
3. "Symbol 解体新書(An instruction manual)"
4. "NEMTUS LT Monthly Document Collection vol.1 / vol.2".

Please take this opportunity to get acquainted with Symbol blockchain technology.

[NEMTUS](https://nemtus.com)
[NEMTUS Official Twitter](https://twitter.com/NemtusOfficial?s=20)


large_NEMTUS-gijyutusyoten.jpeg

medium_NEMTUS-gijyutusyoten.jpeg

small_NEMTUS-gijyutusyoten.jpeg

thumbnail_NEMTUS-gijyutusyoten.jpeg

NEMTUS-gijyutusyoten.jpeg

技術書典は、ITや科学などの技術についての本などを頒布したり買ったりできるイベントで、2023年5月20日(土)から技術書典14が開催されます。

[公式サイト](https://techbookfest.org)

* オンライン開催 
〈会期〉2023年5月20日(土) 10:00 ～6月4日(日) 23:59 
〈会場〉[技術書典オンラインマーケット](https://techbookfest.org/market)  

* オフライン開催 
〈会期〉2023年5月21日(日)
〈会場〉[池袋サンシャインシティ](https://sunshinecity.jp) 展示ホールD（文化会館ビル2F）


特定非営利活動法人NEM技術普及推進会NEMTUSは、日本において「NEM（ネム）」と「Symbol（シンボル）」技術の普及や発展を促進するNPO法人です。
![NEMTUS.PNG](/uploads/NEMTUS_acd681ed60.PNG)

今回の技術書典14にNEMTUSが出展する書籍は、

1. 「速習Symbol  Javascript 版」
2. 「速習Symbol   C# 版」
3. 「Symbol 解体新書」
4. 「月刊NEMTUS  LT 資料集 vol.1 / vol.2」

の4種類です。この機会に是非Symbolブロックチェーンの技術に触れてみてください。

[特定非営利活動法人NEM技術普及推進会NEMTUS](https://nemtus.com)
[NEMTUS公式Twitter](https://twitter.com/NemtusOfficial?s=20)


技術書典14 にNEMTUSが出展します

테크니컬 서점은 IT, 과학 및 기타 기술에 관한 서적과 기타 출판물을 배포 및 판매하는 행사로, 제14회 테크니컬 서점은 2023년 5월 20일부터 개최될 예정입니다.

[Technical Bookstore 14 Official website](https://techbookfest.org) 

* Online 
〈Dates〉20 May 2023 10:00(JST)~4 June 23:59(JST) 
〈Venue〉[Technical Bookstore Online Market](https://techbookfest.org/market)  

* Offline 
〈Date〉21 May 2023 11:00~17:00(JST)
〈Venue〉[Ikebukuro Sunshine City](https://sunshinecity.jp/ko/) Exhibition Hall D (Bunka Kaikan Building 2F)

NEMTUS(特定非營利活動法人NEM技術普及推進会NEMTUS)는 일본에서 넴과 심볼 기술을 홍보하고 발전시키는 것을 목표로 하는 비영리 단체입니다.
![NEMTUS.PNG](/uploads/NEMTUS_acd681ed60.PNG)

이번 테크니컬 북스토어 14에서 NEMTUS 가 전시할 도서는 다음과 같습니다.

1. "Quick Learning Symbol" Javascript edition
2. "Quick Learning Symbol" C# Edition
3. "Symbol 解体新書(An instruction manual)"
4. "NEMTUS LT Monthly Document Collection vol.1 / vol.2".

이번 기회를 통해 심볼 블록체인 기술에 대해 알아보세요.

[NEMTUS](https://nemtus.com)
[NEMTUS Official Twitter](https://twitter.com/NemtusOfficial?s=20)


테크니컬 북스토어 14에서 NEMTUS 는 다음을 전시합니다

技术书店是一个分发和销售有关资讯技术、科学及其他技术相关书籍和出版物的活动，而第14届技术书店将于2023年5月20日举行。

[官方网站第14届技术书店](https://techbookfest.org) 

* 线上活动 
〈日期〉2023年5月20日10:00(JST)~6月4日23:59(JST) 
〈场地〉[技术书店线上市集](https://techbookfest.org/market)  

* 离线活动 
〈日期〉2023年5月21日 11:00~17:00(JST)
〈场地〉[池袋太阳城](https://sunshinecity.jp/zh-cn/) 展览厅D（文化会馆2楼）

NEMTUS（特定非营利活动法人NEM技术普及推进会NEMTUS）是一个旨在推广和发展NEM和Symbol技术在日本的非营利组织。
![NEMTUS.PNG](/uploads/NEMTUS_acd681ed60.PNG)

NEMTUS在第14届技术书店展上展出的书籍包括：

1. 《快速学习Symbol》JavaScript 版本
2. 《快速学习Symbol》C# 版本
3. 《Symbol 解体新书》解说指南版
4. 《NEMTUS LT 月报文选》第一册 / 第二册

请利用这个机会熟悉一下 Symbol 区块链技术。

[NEMTUS](https://nemtus.com)
[NEMTUS官方推特](https://twitter.com/NemtusOfficial?s=20)


NEMTUS 将在第 14 届技术书店展览会上展出。

技術書店是一個分發和銷售有關資訊技術、科學及其他技術相關書籍和出版物的活動，而第14屆技術書店將於2023年5月20日舉行。

[官方網站第14屆技術書店](https://techbookfest.org) 

* 線上活動 
〈日期〉2023年5月20日10:00(JST)~6月4日23:59(JST) 
〈場地〉[技術書店線上市集](https://techbookfest.org/market)  

* 離線活動 
〈日期〉2023年5月21日 11:00~17:00(JST)
〈場地〉[池袋太陽城](https://sunshinecity.jp/zh-cn/) 展覽廳D（文化會館2樓）

NEMTUS（特定非營利活動法人NEM技術普及推進會NEMTUS）是一個旨在推廣和發展NEM和Symbol技術在日本的非營利組織。
![NEMTUS.PNG](/uploads/NEMTUS_acd681ed60.PNG)

NEMTUS在第14屆技術書店展上展出的書籍包括：

1. 《快速學習Symbol》JavaScript 版本
2. 《快速學習Symbol》C# 版本
3. 《Symbol 解體新書》解說指南版
4. 《NEMTUS LT 月報文選》第一冊 / 第二冊

請利用這個機會熟悉一下 Symbol 區塊鏈技術。

[NEMTUS](https://nemtus.com)
[NEMTUS官方推特](https://twitter.com/NemtusOfficial?s=20)


NEMTUS 將在第 14 屆技術書店展覽會上展出。

At the Technical Bookstore 14, NEMTUS will be exhibiting

An interview with [Opening Line, Inc.](https://www.opening-line.co.jp) was featured in a customer story about [LAC Co, Ltd, ](https://www.lac.co.jp/english/)which supports blockchain implementations by providing security assessments and other services. This article includes stories about initiatives such as blockchain technology, the file transfer service "JUGGLE", and Green Life Points for food and living from Opening Line, Inc.

[[Customer Story] Blockchain-fascinated forerunner, Opening Line, Inc., looks to a tamper-free world.](https://www.lac.co.jp/lacwatch/service/20230419_003362.html)

thumbnail_ReadRobot_Avatar_Twitter_400px.png

ReadRobot_Avatar_Twitter_400px.png

[Opening Line, Inc.](https://www.opening-line.co.jp)的访问被收录在关于支持区块链实施的安全评估和其他服务提供的[LAC有限公司](https://www.lac.co.jp/english/)的客户故事中。这篇文章包括了Opening Line, Inc.针对区块链技术、文件传输服务“JUGGLE”以及绿色生活积分等倡议的故事。

[[Customer Story] Blockchain-fascinated forerunner, Opening Line, Inc., looks to a tamper-free world.](https://www.lac.co.jp/lacwatch/service/20230419_003362.html)

对区块链着迷的先行者 Opening Line, Inc. 期待一个无篡改的世界。

[Opening Line, Inc.](https://www.opening-line.co.jp)的訪問被收錄在關於支持區塊鏈實施的安全評估和其他服務提供的[LAC有限公司](https://www.lac.co.jp/english/)的客戶故事中。這篇文章包括了Opening Line, Inc.針對區塊鏈技術、文件傳輸服務“JUGGLE”以及綠色生活積分等倡議的故事。

[[Customer Story] Blockchain-fascinated forerunner, Opening Line, Inc., looks to a tamper-free world.](https://www.lac.co.jp/lacwatch/service/20230419_003362.html)

對區塊鏈著迷的先行者 Opening Line, Inc. 期待一個無篡改的世界。

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

보안 평가 등의 서비스를 제공함으로써 블록체인 도입을 지원하는 [LAC Co., Ltd.](https://www.lac.co.jp/english/) 의 고객 스토리에서 [Opening Line, Inc.](https://www.opening-line.co.jp) 오프닝 라인]과의 인터뷰가 실렸습니다. 이 기사에는 블록체인 기술, 파일 전송 서비스 'JUGGLE', 식생활용 그린 라이프 포인트 등의 이니셔티브에 대한 오프닝 라인의 이야기가 담겨 있습니다.

[[Customer Story] Blockchain-fascinated forerunner, Opening Line, Inc., looks to a tamper-free world.](https://www.lac.co.jp/lacwatch/service/20230419_003362.html)

블록체인에 매료된 선구자, Opening Line, Inc. 이 바라보는 변조 없는 세상

セキュリティ診断などのサービス提供によって、ブロックチェーンの実装をサポートしている[株式会社ラック](https://www.lac.co.jp)のカスタマーストーリーに、[株式会社Opening Line](https://www.opening-line.co.jp)のインタビュー記事が掲載されました。この記事では、株式会社Opening Line社のブロックチェーン技術、ファイル送信サービスJUGGLE、食と暮らしのグリーンライフポイントなどの取り組みについてのお話しが掲載されています。

[【カスタマーストーリー】ブロックチェーンに魅入られたフォアランナー（先駆者）、Opening Lineが見据える改ざんのない世界](https://www.lac.co.jp/lacwatch/service/20230419_003362.html)

ブロックチェーンに魅入られたフォアランナー（先駆者）、Opening Lineが見据える改ざんのない世界

Blockchain-fascinated forerunner, Opening Line, Inc., looks to a tamper-free world.

![nft_drive_logo_cover.jpg](/uploads/nft_drive_logo_cover_0a16b09d3c.jpg)

NFTDrive Co., Ltd. provides a variety of services centred around the "NFTDrive", an Fully-on-chain NFT uploader that leverages the function of the Symbol blockchain and stores both tokens and digital data in a bound state on the blockchain. Fully-on-chain NFT storage technique (also known as On-chain/All-on-chain) means that the entire NFT data exists on the blockchain.

The main service, NFTDrive, is a powerful tool based on the concept of 'Making it easy for anyone to create Fully-on-chain NFTs' using patent-pending technology (application number 2021-143574).

Fully-on-chain NFT means that all NFT data resides on the blockchain. As such, Fully-on-chain NFT can also be used for archiving and data protection.Files that can be NFTised using NFTDrive include GIF, JPEG, PNG, SVG, MIDI, MP3, MP4, Text, PDF, HTML(CSS Javascript) are confirmed to work.

Data stored on the NFT by NFTDrive can be retrieved from the blockchain at any time, and as long as the blockchain exists, the data will continue to exist. It can also be embedded in a website or attached to an email.

![NFTDrive.jpeg](/uploads/NFT_Drive_0251b94fab.jpeg)

Products and services
- Issuing Fully-on-chain NFTs
- Provision of a viewer for issued Fully-on-chain NFTs.
- Provision of tools, planning and operational support services for the generative Fully-on-chain NFTs. 
- Development of dedicated wallets for NFTs transferring and exchange.
- Blockchain technical consulting.

Please visit the URL below for more details.
[NFTDrive Co., Ltd.](https://nftdrive.net)
[株式会社NFTDriveが「ブロックチェーンSymbol」をデジタルデータの保存先として活用！！](https://prtimes.jp/main/html/rd/p/000000002.000119487.html)
[Symbol活用したフルオンチェーンNFTを簡単に「株式会社NFTDrive」設立](https://bittimes.net/news/143500.html)


large_NFTDrive.jpeg

medium_NFTDrive.jpeg

small_NFTDrive.jpeg

thumbnail_NFTDrive.jpeg

NFTDrive.jpeg

![nft_drive_logo_cover.jpg](/uploads/nft_drive_logo_cover_0a16b09d3c.jpg)

"NFT-Drive"有限公司提供圍繞著"NFT-Drive"展開的多種服務，該服務是一個"Fully-on-chain"的NFT上傳工具，利用Symbol區塊鏈的功能，將代幣和數字數據以綁定狀態存儲在區塊鏈上。"Fully-on-chain" 的NFT存儲技術（也稱為On-chain/All-on-chain）意味著整個NFT數據存在於區塊鏈上。

主要服務"NFT-Drive"是一個基於讓任何人輕鬆創建"Fully-on-chain" 的NFT概念的強大工具，使用了專利申請中的技術（申請號為2021-143574）。

"Fully-on-chain" 生成的NFT意味著所有NFT數據都存儲在區塊鏈上。因此，"Fully-on-chain" 的NFT也可用於存檔和數據保護。可使用"NFT-Drive"將以下檔案轉換為NFT：GIF、JPEG、PNG、SVG、MIDI、MP3、MP4、Text、PDF、HTML（CSS JavaScript）已被證實可以運作。

由"NFT-Drive"存儲的數據可以隨時從區塊鏈中檢索，只要區塊鏈存在，數據就會繼續存在。它還可以嵌入到網站中或附加到電子郵件中。 

![NFTDrive.jpeg](/uploads/NFT_Drive_0251b94fab.jpeg)

產品和服務
- 發行Fully-on-chain的 NFTs 。
- 提供發行的Fully-on-chain NFTs 的查看器。
- 提供生成Fully-on-chain  NFT 的工具、規劃和操作支援服務。
- 開發專用的錢包，用於 NFT 的轉移和交換。
- 區塊鏈技術諮詢。

請訪問下面的網址以獲取更多詳細資訊。
[NFTDrive Co., Ltd.](https://nftdrive.net)
[株式会社NFTDriveが「ブロックチェーンSymbol」をデジタルデータの保存先として活用！！](https://prtimes.jp/main/html/rd/p/000000002.000119487.html)
[Symbol活用したフルオンチェーンNFTを簡単に「株式会社NFTDrive」設立](https://bittimes.net/news/143500.html)

NFTDrive有限公司使用 Symbol 區塊鏈存儲數字資料。

![nft_drive_logo_cover.jpg](/uploads/nft_drive_logo_cover_0a16b09d3c.jpg)

“NFT-Drive"有限公司提供围绕着"NFT-Drive"展开的多种服务，该服务是一个"Fully-on-chain"的NFT上传工具，利用Symbol区块链的功能，将代币和数字数据以绑定状态存储在区块链上。"Fully-on-chain" 的NFT存储技术（也称为On-chain/All-on-chain）意味着整个NFT数据存在于区块链上。

主要服务"NFT-Drive"是一个基于"让任何人轻松创建"Fully-on-chain" 的NFT"概念的强大工具，使用了专利申请中的技术（申请号为2021-143574）。

"Fully-on-chain" 生成的NFT意味着所有NFT数据都存储在区块链上。因此，"Fully-on-chain" 的NFT也可用于存档和数据保护。可使用"NFT-Drive"将以下档案转换为NFT：GIF、JPEG、PNG、SVG、MIDI、MP3、MP4、Text、PDF、HTML（CSS JavaScript）已被证实可以运作。

由"NFT-Drive"存储的数据可以随时从区块链中检索，只要区块链存在，数据就会继续存在。它还可以嵌入到网站中或附加到电子邮件中。

![NFTDrive.jpeg](/uploads/NFT_Drive_0251b94fab.jpeg)

产品和服务
- 发行Fully-on-chain 的 NFTs 。
- 提供发行的Fully-on-chain  NFTs 的查看器。
- 提供生成Fully-on-chain  NFT 的工具、规划和操作支援服务。
- 开发专用的钱包，用于 NFT 的转移和交换。
- 区块链技术咨询。

请访问下面的网址以获取更多详细资讯。
[NFTDrive Co., Ltd.](https://nftdrive.net)
[株式会社NFTDriveが「ブロックチェーンSymbol」をデジタルデータの保存先として活用！！](https://prtimes.jp/main/html/rd/p/000000002.000119487.html)
[Symbol活用したフルオンチェーンNFTを簡単に「株式会社NFTDrive」設立](https://bittimes.net/news/143500.html)

NFTDrive有限公司使用 Symbol 区块链存储数字资料。

![nft_drive_logo_cover.jpg](/uploads/nft_drive_logo_cover_0a16b09d3c.jpg)

株式会社NFTDriveは、Symbolブロックチェーンの特性を活かし、トークンとデジタルデータを紐づけた状態で両⽅ともブロックチェーン上に保存する「フルオンチェーンNFT」のアップロードツール【NFTDrive】を軸に、様々なサービスを提供してます。
メインサービスであるNFTDriveは、特許出願済み(出願番号2021-143574)の技術を活用し、「誰でも簡単にフルオンチェーンNFTを⽣成することができる」をコンセプトに開発された強⼒なツールです。

フルオンチェーンNFTは、データを直接ブロックチェーンに保存しますので、アーカイブや保護にも使えます。NFTDriveでNFTにすることができるファイルは、 GIF, JPEG, PNG, SVG, MIDI, MP3, MP4, Text, PDF, HTML(CSS Javascript) などが動作確認済みです。

保存されたデータは、いつでもブロックチェーンから取り出すことができ、ブロックチェーンが存続する限り、データも存在し続けます。また、WEBサイトに埋め込んだりメールに添付することも出来ます。


![NFTDrive.jpeg](/uploads/NFT_Drive_0251b94fab.jpeg)

代表的なサービス
フルオンチェーンNFT発⾏
発⾏したフルオンチェーンNFTのプレビューツールの提供
ジェネラティブフルオンチェーンNFTのツール提供・企画・運⽤⽀援サービス
NFT交換⽤の専⽤ウォレットの開発
ブロックチェーンの技術コンサルティング

詳しくはリンク先をご覧ください
[株式会社NFTDrive ](https://nftdrive.net)
[株式会社NFTDriveが「ブロックチェーンSymbol」をデジタルデータの保存先として活用！！](https://prtimes.jp/main/html/rd/p/000000002.000119487.html)
[Symbol活用したフルオンチェーンNFTを簡単に「株式会社NFTDrive」設立](https://bittimes.net/news/143500.html)




株式会社NFTDriveが「ブロックチェーンSymbol」をデジタルデータの保存先として活⽤！！

![nft_drive_logo_cover.jpg](/uploads/nft_drive_logo_cover_0a16b09d3c.jpg)

NFTDrive Co., Ltd. 는 심볼 블록체인의 기능을 활용하여 토큰과 디지털 데이터를 모두 블록체인에 바인딩된 상태로 저장하는 Fully-on-chain NFT 업로더인 "엔에프티드라이브"를 중심으로 다양한 서비스를 제공하고 있습니다. Fully-on-chain NFT 저장 기술(On-chain/All-on-chain 이라고도 함)은 전체 NFT 데이터가 블록체인에 존재한다는 의미입니다.

메인 서비스인 NFTDrive는 특허 출원 중인 기술(출원번호 2021-143574)을 사용하여 '누구나 쉽게 *Fully-on-chain NFTs 를 만들 수 있도록 한다'는 컨셉을 기반으로 하는 강력한 툴입니다.

Fully-on-chain NFT 는 모든 NFT 데이터가 블록체인에 상주하는 것을 의미합니다. 따라서 Fully-on-chain NFT 는 아카이빙 및 데이터 보호에도 사용할 수 있습니다. NFTDrive 를 사용하여 NFT화할 수 있는 파일은 GIF, JPEG, PNG, SVG, MIDI, MP3, MP4, 텍스트, PDF, HTML(CSS 자바스크립트) 등이며, 작동이 확인되었습니다.

NFTDrive에 의해 NFT에 저장된 데이터는 언제든지 블록체인에서 검색할 수 있으며 블록체인이 존재하는 한 데이터는 계속 존재합니다. 웹사이트에 퍼가거나 이메일에 첨부할 수도 있습니다.


![NFTDrive.jpeg](/uploads/NFT_Drive_0251b94fab.jpeg)

제품 및 서비스
- Fully-on-chain NFTs 발행
- 발행된 Fully-on-chain NFTs 에 대한 뷰어 제공.
- Generative Fully-on-chain NFTs 를 위한 도구, 계획 및 운영 지원 서비스 제공.
- NFTs 전송 및 교환을 위한 전용 지갑 개발.
- 블록체인 기술 컨설팅.


자세한 내용은 아래 URL을 참조하세요.
[NFTDrive Co., Ltd.](https://nftdrive.net)
[株式会社NFTDriveが「ブロックチェーンSymbol」をデジタルデータの保存先として活用！！](https://prtimes.jp/main/html/rd/p/000000002.000119487.html)
[Symbol活用したフルオンチェーンNFTを簡単に「株式会社NFTDrive」設立](https://bittimes.net/news/143500.html)


NFTDrive Co., Ltd. 는 Symbol Blockchain 을 사용하여 디지털 데이터를 저장합니다.

NFTDrive Co., Ltd. uses Symbol Blockchain to store digital data.

![NEMTUS Hackathon Hack+ 2023.png](/uploads/NEMTUS_Hackathon_Hack_2023_a6f0e2631a.png)

In addition to the judging by the jury, there was also a community 'vote'.
The winning entries and the judges' comments are available on a dedicated website.
https://hackathon-2023.nemtus.com


large_NEMTUS Hackathon Hack+ 2023.png

medium_NEMTUS Hackathon Hack+ 2023.png

small_NEMTUS Hackathon Hack+ 2023.png

thumbnail_NEMTUS Hackathon Hack+ 2023.png

NEMTUS Hackathon Hack+ 2023.png

![NEMTUS Hackathon Hack+ 2023.png](/uploads/NEMTUS_Hackathon_Hack_2023_a6f0e2631a.png)

審査員による審査に加え、コミュニティによる「投票」も実施されました。
特設サイトで受賞作品と、審査員によるコメントをご確認いただけます。
https://hackathon-2023.nemtus.com


「NEMTUS Hackathon HACK+2023」　受賞作品が発表されました

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.
![NEMTUS Hackathon Hack+ 2023.png](/uploads/NEMTUS_Hackathon_Hack_2023_a6f0e2631a.png)

심사위원단의 심사 외에도 커뮤니티 '투표'도 있었습니다.
수상작과 심사위원들의 심사평은 전용 웹사이트에서 확인할 수 있습니다.
https://hackathon-2023.nemtus.com


"NEMTUS Hackathon HACK+2023" 의 우승자가 발표되었습니다.

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.
![NEMTUS Hackathon Hack+ 2023.png](/uploads/NEMTUS_Hackathon_Hack_2023_a6f0e2631a.png)

除了评委会的评审，还有社区投票。
获奖作品和评委的评论可在专门的网站上查阅。
https://hackathon-2023.nemtus.com


"NEMTUS Hackathon HACK+2023" 的获奖者已经公布。

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.
![NEMTUS Hackathon Hack+ 2023.png](/uploads/NEMTUS_Hackathon_Hack_2023_a6f0e2631a.png)

除了評委會的評審，還有社區投票。
獲獎作品和評委的評論可在專門的網站上查閱。
https://hackathon-2023.nemtus.com


"NEMTUS Hackathon HACK+2023" 的獲獎者已經公布。

The winners of the "NEMTUS Hackathon HACK+2023" have been announced.

![drugn2-min.png](/uploads/drugn2_min_15775b51f1.png)
【Web3 meets medication】Healthcare against the backdrop of various social issues and challenges, "DrugN" from Japan aims to create an optimal healthcare environment that motivates patients to feel more positive by implementing “incentive healthcare apps” by accelerating their own self-esteem and relationship with healthcare professionals. Users can use it on a “completely anonymous” basis, to comply with a personal data protection act as a global standard for the SDGs. This is a medication record traceability application that solves industry problems with user behaviour DX, which has been adopted as a local government support project.


A health life-log app with elements of Medical-fi, Social-fi and Game-fi that encourages and incentivizes the correct use of prescribed medication with anonymous use and no registration of personal data. Through anonymous medication records, we are trying to solve social issues with the full involvement of users, medical institutions and related companies.



## What kind of service does “DrugN” provide?

DrugN aims to support patients in their efforts to lead a healthy life. Patients can be affected both physically and mentally when they have a difficult-to-treat disease, or having some restrictions in their lives due to their illness and when they are distressed by their illness. The idea is that this would be one of the cues for these patients to have their life with a positive attitude through the service. Therefore, this app has a target to turn their health behaviour into value by introducing a system that allows them to earn points and crypto assets(tokens), the timing of medication, each time patients take pills, will be a trigger of transaction. The points and crypto assets(tokens) will not be issued indefinitely by the management, but will be targeted to properties that have value when activated by the patients themselves.

## What is behind the adoption of blockchain technology?

The use of a centralised database could reduce reliability, as administrators can change data at will. Blockchain, on the other hand, is a decentralised system in which transactions are stored in the form of a series of chains, making them much harder to tamper with and allowing for a more reliable and transparent system. Blockchain also allows users to manage their own value, making the system more autonomous. Therefore, points/crypto assets (tokens) enabled by blockchain technology are seen as a suitable alternative to centralised databases.


It is encouraging to see from the Twitter feed that activated testers are sending their tokens to other self-custody wallets that we can see.


The purpose of medicines is to function in a way that creates a state of social activity through healthy living, and are tools for achieving social sustainability and development, and are only valuable if used appropriately.
We believe that there is value in the appropriate use of medicines, in patients investing in their own bodies, and in a sustainable society with increased healthy life expectancy, and we are developing DrugN as a tool that can be used autonomously by patients to make this a reality.
From this perspective, blockchain technology has been adopted with the aim of creating a healthcare application that is anonymous, with a point system that patients find free and enjoyable, in order to increase social sustainability.

## What was the point of choosing Symbol out of several blockchains?
![drugn3.png](/uploads/drugn3_4762dc4d03.png)
On the Symbol blockchain, users can participate in block validation by hosting nodes, and get rewarded which is called harvesting, and even if they don't host their node, they can participate in the process by delegating to the node, which is called delegated harvesting, and this is where the incentives come in. 

At the moment, the blockchain still has some difficulties, such as the hosting nodes, the way accounts and wallets, and especially the management of private key, but Symbol has already achieved a degree of decentralisation and has two years of working history. It was also important that the origin of the Symbol blockchain NEM also had a proven history.

On the other hand, there is a concern. This is the case with other blockchains, but because the native currency of the Symbol blockchain, XYM, is used to pay for server management costs, if the price of XYM, which is used to pay the fees, goes up, the divergence in profitability may change and the costs may not be paid. In such a situation, it may be necessary to consider relocating with records on another chain, but the timing is unpredictable and therefore a concern for management. 

However, Symbol has the potential to solve this problem. As mentioned above, this is a harvesting/delegated harvesting of the block validation process to keep the chain stable. If management can host their node to be delegated, management will be incentivised by that block validation and we believe this is a solution that will allow us to continue the business without being impacted to some extent by cost issues. 
And we are currently using our own servers on a trial basis to host our Node: https://symbol-01.drugn.life and increase our knowledge while providing node operation.
In the future, we would like to achieve a certain reputation for DrugN in the Symbol blockchain ecosystem, and it would be gratifying to see if we are supported by users through delegations to our node, this is a challenging goal we think.

As the DrugN app uses Symbol, it is important that the Symbol blockchain remains in use and alive for a long time; when DrugN is used, a Symbol account is automatically created, increasing the number of users and transactions.

By using the Symbol blockchain, we can use blockchain transactions to keep historical records of medicines, and users who host the nodes and also harvesters can earn block rewards that include transaction fees. To use public blockchains, the support of investors and fan users of the chain technology is necessary for the technological development itself to be sustainable. We think that the way to support the activity and give back to the users needs careful consideration, but the DrugN team believes that the situation of Symbol in Japan, which has many enthusiastic users and community, is a very promising environment for us.


In the future, we will be working around VC to raise funds, so it will be helpful for our activities if we have the support of many users, a track record, node delegation, etc.
Please continue to give us your feedback on the app. Feedback improves its potential for social implementation.
Thank you for listening. Your support means a lot to us.


[HealthCareGate Co., Ltd.](https://healthcaregate.co.jp/)
[DrugN White Paper](https://drugn.gitbook.io/whitepaper.drugn.life/)
Node : https://symbol-01.drugn.life

medium_drugn2-min.png

small_drugn2-min.png

thumbnail_drugn2-min.png

drugn2-min.png

![drugn2-min.png](/uploads/drugn2_min_15775b51f1.png)
【Web3x医薬品】患者さんの気持ちを前向きにシフトすることを支援する”インセンティブ型ヘルスケアアプリ”を具体化することで、さまざまな社会的問題と課題を背景に、患者さん自身の自己肯定感及び医療従事者との関係性を加速し、最適な医療環境を創出する。それをSDGsが求められるグローバルに適合する個人情報保護法等をクリアするための”完全匿名”での参加利用も可能に実現させる。行政事業に採択されたユーザー行動DXで業界課題を解決する服薬記録トレーサビリティアプリ「DrugN」です。  
薬を処方箋通りに正しく服用することを奨励し、インセンティブ提供するmedical-fi・Social-Fi・Game-fiの要素を取り入れた匿名ヘルスケアライフログアプリです。匿名での服薬記録を通じてユーザーから医療機関、関連企業までを巻き込んだ課題解決に取り組もうとしています。

## 「DrugN」はどんなサービスなのでしょうか。

DrugNは健康的な生活を送るために努力する患者さんを支援することを目的としています。患者さんは、完治が難しい、生活に制限がある、病気に悩みを抱えると精神的にも影響を受けることがあります。このような患者さんに対し、サービスを通じて前向きな気持ちを持って生きるきっかけの１つになることを考えています。そのため、お薬を使うタイミングを起点として、ポイントや暗号資産を獲得できる仕組みを導入することで、患者さんの健康行動を価値に変えることを目指しています。ポイントや暗号資産は、運営が無限に発行するのではなく、患者さん自身がアクティベートすることで価値を持つ性質を目指しています。

## ブロックチェーン技術を採用した経緯はどのようなものでしょうか。

中央集権的なデータベースを使用すると、管理者がデータを任意に変更できるため、信頼性が低下する可能性があります。一方、ブロックチェーンは分散型管理であり、取引が連鎖的な形式で保存され、改ざんが不可能で信頼性が高く、透明性の高いシステムを実現できます。また、ブロックチェーンを利用することで、ユーザー自身が自分の価値を管理できるため、より自律的なシステムを実現できます。そのため、ブロックチェーン技術で実現されるトークン/ポイントは、中央集権的なデータベースの代替として適していると考えられます。  
嬉しいことに実際にツイッターを見ていると、ユーザーがアクティベートしたテスター向けのトークンを他の管理walletに送信している様子も伺えます。
医薬品の目的は人々の健康を通じて社会活動ができる状態を作るような機能をもち、社会の持続可能化、発展の実現を目指すためのツールで、適切に使われてこそ価値があります。
DrugNは医薬品を適切に使用し、患者さんは自身の体への投資を行い、健康寿命が伸びて持続可能な社会が続くことに、価値があると考えているため、これを現実のものに変えられるよう、患者さんが自律的に活用可能なツールを目指し開発しているところです。  
これらの観点から、社会の持続可能性を高めるために患者さんに自由で楽しいと思ってもらえるポイントシステムを搭載し、匿名に近い状態で利用できるヘルスケアアプリを目指して、ブロックチェーン技術を採用しました。

## ブロックチェーン技術のなかでもSymbolを採用した経緯を教えてください。
![drugn3.png](/uploads/drugn3_4762dc4d03.png)
Symbolブロックチェーンは、ユーザー自身が存続に対するインセンティブを持ち、ブロック生成の承認を他人に委任することもできる仕組みでチェーンを維持することができます。現状では、ノードの構築やウォレットの普及、特に秘密鍵の取り扱いの一般化は難しいため、完全な分散化をされているわけではありませんが、一定の分散化が実現されており、2年間機能している実績があります。また、元となっているNEMにも実績があることは重要でした。  

一方で問題はあります。他のブロックチェーンでも同じことが言えますが、サーバーの管理料としてネイティブ通貨であるXYMを使用しているため、取引手数料に使用するトークン価格高騰によって採算分岐点が変化し、取引手数料が支払えなくなる可能性があることが考えられます。また、このような状況が発生した場合、チェーン上の記録とともに引っ越しを検討する必要があり、その時期が不透明であるため、事業者としては懸念すべき事項であると考えます。  

ただし、この問題についてSymbolには一定の解決可能性があります。それは先ほども述べましたが、チェーンが存続するために第３者が管理するノードにブロックの承認処理を委任できるという性質があります。委任をされるノードを運営できる場合はこのブロック生成によるインセンティブを受けることができるので、一定程度の上昇であれば手数料の高騰に左右されることなく事業を存続できる解決策を持っていると確信しています。  
現在は試験的に自社サーバーを用いたNode:https://symbol-01.drugn.life を立ててNodeの運用ノウハウを提供しながら知見を高めています。  
将来的にDrugNがSymbolブロックチェーンエコノミーの中で、一定のご評価をいただきながら、ノードへの応援/委任していただける可能性もあると感じており、その点は目指していこうと考えています。

DrugNの利用には、Symbolを活用していますから、そのブロックチェーンが長く生きていくことが、重要です、DrugNが使われるとSymbol上のウォレットが自動的に生成され、これにより利用者やトランザクション数が増えます。  
ノード構築者やハーベスターは実入りのトランザクションを得ることができるようになり、弊社側は記録をつけることができるようになります。パブリックブロックチェーンを活用するためには、そのチェーン技術への投資家やファンユーザーの支援が技術自体の持続可能性で必要であり、この支援の程度と還元の方法については慎重に考える必要がありますが、DrugNチームとしてはSymbolの日本における状況は、弊社にとってとても可能性のある環境だと考えています。  

今後は資金調達の為に、VC周りを行っていくので多くのユーザーによる応援や実績、ノード委任等があると活動がしやすいです。  
また率直なアプリへのフィードバックをいただけるとより社会実装の可能性が高まりますので、どうぞ引き続きよろしくお願い申し上げます。
この度は、お話を聞いていただきまして誠にありがとうございました。


[株式会社HealthCareGate](https://healthcaregate.co.jp/)
[ホワイトペーパー](https://drugn.gitbook.io/whitepaper.drugn.life/)
Node : https://symbol-01.drugn.life

匿名の服薬記録を通じユーザーから関連企業までを巻き込んだ課題解決を取り組む「DrugN」

【Web3x医薬品】行政事業に採択された服薬記録トレーサビリティアプリ「DrugN」

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![drugn2-min.png](/uploads/drugn2_min_15775b51f1.png)
【Web3과 의약품의 만남】다양한 사회적 문제와 도전에 직면한 헬스케어 분야에서 일본의 'DrugN'은 '인센티브 헬스케어 앱'을 통해 환자 스스로의 자존감과 의료 전문가와의 관계를 증진시켜 긍정적인 동기를 부여하는 최적의 헬스케어 환경을 조성하는 것을 목표로 합니다. 사용자는 '완전 익명'으로 사용할 수 있으며, SDGs의 글로벌 표준인 개인정보 보호법을 준수합니다. 사용자 행동 DX를 통해 업계의 문제를 해결하는 의약품 기록 추적 애플리케이션으로, 지자체 지원 사업으로 채택된 바 있습니다.


개인 정보를 등록하지 않고 익명으로 처방받은 약을 올바르게 사용하도록 장려하고 인센티브를 제공하는 Medical-fi, Social-fi and Game-fi 의 요소를 갖춘 건강 라이프로그 앱입니다. 익명 투약 기록을 통해 사용자, 의료기관, 관련 기업이 함께 참여하여 사회 문제를 해결하고자 합니다.



## "DrugN"은 어떤 서비스를 제공하나요?

"DrugN"은 환자들이 건강한 삶을 영위할 수 있도록 지원하는 것을 목표로 합니다. 환자들은 치료가 어려운 질병을 앓고 있거나 질병으로 인해 생활에 제약이 있을 때, 그리고 질병으로 인해 괴로울 때 신체적, 정신적으로 많은 영향을 받을 수 있습니다. 이러한 환자들이 서비스를 통해 긍정적인 태도로 삶을 살아갈 수 있는 단서 중 하나가 될 수 있을 것이라는 생각입니다. 따라서 이 앱은 환자가 약을 복용할 때마다 약 복용 시점이 거래의 트리거가 되어 포인트와 암호화폐(토큰)를 획득할 수 있는 시스템을 도입하여 환자의 건강 행동을 가치로 전환하는 것을 목표로 하고 있습니다. 포인트와 암호화폐(토큰)는 운영진에 의해 무한정 발행되는 것이 아니라, 환자 스스로가 활성화했을 때 가치가 있는 자산을 대상으로 합니다.

## 블록체인 기술을 도입하게 된 배경은 무엇인가요?

중앙화된 데이터베이스를 사용하면 관리자가 마음대로 데이터를 변경할 수 있기 때문에 신뢰성이 떨어질 수 있습니다. 반면 블록체인은 거래가 일련의 체인 형태로 저장되는 탈중앙화 시스템으로, 위변조가 훨씬 어렵고 보다 안정적이고 투명한 시스템을 구축할 수 있습니다. 또한 블록체인은 사용자가 자신의 가치를 직접 관리할 수 있어 시스템을 더욱 자율적으로 운영할 수 있습니다. 따라서 블록체인 기술로 구현된 포인트/암호 자산(토큰)은 중앙 집중식 데이터베이스의 적절한 대안으로 여겨지고 있습니다.


트위터 피드에서 활성화된 테스터들이 토큰을 다른 자체 보관 지갑으로 보내는 것을 볼 수 있다는 것은 고무적인 일입니다.


의약품의 목적은 건강한 생활을 통해 사회적 활동 상태를 만드는 방식으로 기능하는 것이며, 사회적 지속 가능성과 발전을 달성하기 위한 도구로서 적절하게 사용될 때만 가치가 있습니다.
우리는 의약품의 적절한 사용, 환자의 자기 몸에 대한 투자, 건강수명 연장으로 지속 가능한 사회에 가치가 있다고 믿으며, 이를 실현하기 위해 환자가 자율적으로 사용할 수 있는 도구로서 DrugN 을 개발하고 있습니다.
이러한 관점에서 블록체인 기술은 익명성이 보장되고 환자들이 자유롭고 즐겁게 사용할 수 있는 포인트 시스템을 갖춘 의료 애플리케이션을 만들어 사회적 지속 가능성을 높이기 위해 채택되었습니다.

## 여러 블록체인 중에서 Symbol 을 선택한 이유는 무엇인가요?
![drugn3.png](/uploads/drugn3_4762dc4d03.png)
Symbol 블록체인에서는 사용자가 노드를 호스팅하여 블록 검증에 참여하고 보상을 받을 수 있는데, 이를 하베스팅이라고 하며, 노드를 호스팅하지 않더라도 노드에 위임하여 프로세스에 참여할 수 있는데, 이를 위임 하베스팅이라고 하며, 여기서 인센티브가 발생합니다. 

현재 블록체인은 호스팅 노드, 계정 및 지갑 방식, 특히 개인 키 관리와 같은 몇 가지 어려움이 있지만 Symbol 은 이미 어느 정도의 탈중앙화를 달성했으며 2 년의 작업 이력을 가지고 있습니다. 또한 Symbol 블록체인의 기원이 된 NEM의 역사 또한 입증된 역사를 가지고 있다는 점도 중요했습니다.

반면에 우려되는 점도 있습니다. 다른 블록체인도 마찬가지이지만, Symbol 블록체인의 기축 통화인 XYM을 서버 관리 비용으로 지불하기 때문에 수수료 지불에 사용되는 XYM의 가격이 상승하면 수익성 격차가 달라져 비용을 지불하지 못할 수도 있습니다. 이러한 상황에서는 다른 체인의 기록으로 이전을 고려해야 할 수도 있지만, 그 시기를 예측할 수 없으므로 관리가 우려됩니다. 

하지만 Symbol 은 이 문제를 해결할 수 있는 잠재력을 가지고 있습니다. 위에서 언급했듯이, 이는 체인을 안정적으로 유지하기 위한 블록 검증 프로세스의 하베스팅/위임 하베스팅입니다. 경영진이 위임할 노드를 호스팅할 수 있다면, 경영진은 블록 검증을 통해 인센티브를 받게 될 것이며, 이는 비용 문제에 어느 정도 영향을 받지 않고 비즈니스를 지속할 수 있는 솔루션이라고 생각합니다. 
그리고 현재 자체 서버를 시범적으로 사용하여 노드를 호스팅하고 있습니다: https://symbol-01.drugn.life 노드 운영을 제공하면서 지식을 쌓고 있습니다.
앞으로 Symbol 블록체인 생태계에서 DrugN 이 어느 정도 명성을 얻고 싶고, 노드 위임을 통해 사용자들의 지지를 받는다면 더할 나위 없이 기쁠 것 같습니다.

DrugN 앱은 Symbol 을 사용하기 때문에 Symbol 블록체인을 오랫동안 사용하고 유지하는 것이 중요하며, DrugN 을 사용하면 Symbol 계정이 자동으로 생성되어 사용자 및 거래 수가 증가합니다.

Symbol 블록체인을 사용하면 블록체인 거래를 통해 의약품의 이력 기록을 보관할 수 있으며, 노드를 호스팅하는 사용자 및 수확자는 거래 수수료가 포함된 블록 보상을 받을 수 있습니다. 퍼블릭 블록체인을 활용하기 위해서는 기술 개발 자체가 지속 가능하기 위해 체인 기술에 대한 투자자와 팬 유저들의 지지가 필요합니다. 활동을 지원하고 사용자에게 보답하는 방식에 대해서는 신중한 검토가 필요하다고 생각하지만, '드럭앤' 팀은 열성적인 사용자와 커뮤니티가 많은 일본의 Symbol 의 상황이 우리에게 매우 유망한 환경이라고 생각합니다.


앞으로는 VC를 중심으로 펀딩을 진행할 예정이므로 많은 사용자분들의 지지와 실적, 노드 위임 등이 있으면 활동에 도움이 될 것입니다.
앞으로도 앱에 대한 피드백을 부탁드립니다. 피드백을 통해 소셜 구현 가능성을 높일 수 있습니다.
경청해 주셔서 감사합니다. 여러분의 성원은 저희에게 큰 의미가 있습니다.


[HealthCareGate Co., Ltd.](https://healthcaregate.co.jp/)
[DrugN White Paper](https://drugn.gitbook.io/whitepaper.drugn.life/)
Node : https://symbol-01.drugn.life

Medication traceability DrugN 약물 추적성

【Web3과 의약품의 만남】의약품 이력추적 애플리케이션 '드럭엔', 지자체 지원 사업에 도입

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![drugn2-min.png](/uploads/drugn2_min_15775b51f1.png)
【Web3遇到藥物治療】在各種社會問題和挑戰的背景下，來自日本的 "DrugN "旨在創造一個最佳的醫療環境，通過實施 "激勵性醫療應用"，加速患者自身的自尊和與醫護人員的關係，使他們感到更加積極。用戶可以在 "完全匿名 "的基礎上使用它，以遵守作為可持續發展目標的全球標準的個人數據保護法。這是一個用用戶行為DX解決行業問題的藥物記錄可追溯性應用，已被採納為地方政府的支持項目。


一款具有医疗（Medical-fi）、社交（Social-fi）和游戏（Game-fi）元素的健康生活记录应用，鼓励和激励人们正确使用处方药物，并采用匿名使用和不登记个人数据的方式。通过匿名的用药记录，我们试图在用户、医疗机构和相关公司的充分参与下解决社会问题。



## DrugN "提供什么样的服务？

DrugN旨在支持病人努力过上健康的生活。当病人患有难以治疗的疾病，或因疾病而在生活中受到一些限制，或因疾病而感到痛苦时，他们的身体和精神都会受到影响。我们的想法是，这将是这些病人的线索之一，通过服务使他们以积极的态度生活。因此，这个应用程序的目标是通过引入一个允许他们赚取积分和加密资产（代币）的系统，将他们的健康行为转化为价值，患者每次吃药的时间将是一个交易的触发点。这些积分和加密资产（代币）不会由管理层无限期发行，而是针对病人自己激活时具有价值的属性。

## 采用区块链技术的背后是什么？

使用集中式数据库可能会降低可靠性，因为管理员可以随意改变数据。另一方面，区块链是一个去中心化的系统，其中交易以一系列链的形式存储，使其更难被篡改，并允许一个更可靠和透明的系统。区块链还允许用户管理自己的价值，使系统更加自主。因此，由区块链技术实现的积分/加密资产（代币）被视为中心化数据库的合适替代品。


从推特上看到被激活的测试者正在将他们的代币发送到我们能看到的其他自我托管钱包，这令人鼓舞。


药品的目的是通过健康生活的方式发挥功能，创造社会活动的状态，是实现社会可持续发展的工具，只有合理使用，才有价值。

我们相信，合理使用药品、患者对自己的身体进行投资，以及一个可持续发展的社会，增加健康的预期寿命，都是有价值的。我们正在开发DrugN，作为一个可以由患者自主使用的工具，以实现这一目标。

从这个角度来看，采用区块链技术的目的是创建一个匿名的医疗保健应用程序，其积分系统让患者感到自由和愉快，以提高社会的可持续性。

## 在几个区块链中选择Symbol的意义何在？
![drugn3.png](/uploads/drugn3_4762dc4d03.png)
在Symbol区块链上，用户可以通过托管节点参与区块验证，并获得奖励，这被称为收获，即使他们不托管自己的节点，他们也可以通过委托给节点来参与这个过程，这被称为委托收获，这就是奖励的来源。

目前，区块链还存在一些困难，如托管节点、方式账户和钱包，尤其是私钥的管理，但Symbol已经实现了一定程度的去中心化，并且有两年的工作历史。同样重要的是，Symbol区块链的起源NEM也有一个成熟的历史。

另一方面，也有一种担忧。其他区块链也是如此，但由于Symbol区块链的原生货币XYM是用来支付服务器管理费用的，如果用来支付费用的XYM价格上涨，盈利能力的分歧可能会改变，费用可能无法支付。在这种情况下，可能需要考虑用另一条链上的记录进行迁移，但时间是不可预测的，因此是管理层的担忧。

然而，Symbol有可能解决这个问题。如上所述，这是一个收获/委托收获的区块验证过程，以保持链的稳定。如果管理层可以主持他们的节点被委托，管理层将受到该区块验证的激励，我们相信这是一个解决方案，将允许我们继续开展业务，而不会在一定程度上受到成本问题的影响。

而我们目前正在试用自己的服务器来托管我们的节点：https://symbol-01.drugn.life，在提供节点操作的同时增加我们的知识。

在未来，我们希望在Symbol区块链生态系统中为DrugN取得一定的声誉，如果我们通过授权给我们的节点而得到用户的支持，这将是令人欣慰的，这是一个具有挑战性的目标，我们认为。

由於DrugN應用程序使用Symbol，Symbol區塊鏈保持長期使用和活力是非常重要的；當DrugN被使用時，Symbol賬戶會自動創建，增加用戶和交易的數量。

通过使用Symbol区块链，我们可以使用区块链交易来保存药品的历史记录，主持节点的用户以及收获者可以获得包括交易费用的区块奖励。为了使用公共区块链，投资者和链上技术的粉丝用户的支持是技术发展本身可持续的必要条件。我们认为支持活动和回馈用户的方式需要慎重考虑，但DrugN团队认为Symbol在日本的情况，有很多热情的用户和社区，对我们来说是非常有希望的环境。


在未来，我们将围绕着VC来筹集资金，所以如果我们有很多用户的支持，有业绩，有节点授权等，对我们的活动会有帮助。

請繼續給我們提供關於該應用程序的反饋。反饋可以提高其社會實施的潛力。

谢谢您的聆听。你的支持对我们意义重大。


[HealthCareGate Co., Ltd.](https://healthcaregate.co.jp/)
[DrugN White Paper](https://drugn.gitbook.io/whitepaper.drugn.life/)
Node : https://symbol-01.drugn.life

Medication traceability DrugN 药品可追溯性

【Web3遇到药物治疗】药品追溯应用 "DrugN "被采纳为地方政府支持项目

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![drugn2-min.png](/uploads/drugn2_min_15775b51f1.png)
【Web3遇到藥物治療】在各種社會問題和挑戰的背景下，來自日本的 "DrugN "旨在創造一個最佳的醫療環境，通過實施 "激勵性醫療應用"，加速患者自身的自尊和與醫護人員的關係，使他們感到更加積極。用戶可以在 "完全匿名 "的基礎上使用它，以遵守作為可持續發展目標的全球標準的個人數據保護法。這是一個用用戶行為DX解決行業問題的藥物記錄可追溯性應用，已被採納為地方政府的支持項目。

一款具有醫療（Medical-fi）、社交（Social-fi）和遊戲（Game-fi）元素的健康生活記錄應用，鼓勵和激勵人們正確使用處方藥物，並採用匿名使用和不登記個人數據的方式。通過匿名的用藥記錄，我們試圖在用戶、醫療機構和相關公司的充分參與下解決社會問題。



## DrugN "提供什麼樣的服務？

DrugN旨在支持病人努力過上健康的生活。當病人患有難以治療的疾病，或因疾病而在生活中受到一些限制，或因疾病而感到痛苦時，他們的身體和精神都會受到影響。我們的想法是，這將是這些病人的線索之一，通過服務使他們以積極的態度生活。因此，這個應用程序的目標是通過引入一個允許他們賺取積分和加密資產（代幣）的系統，將他們的健康行為轉化為價值，患者每次吃藥的時間將是一個交易的觸發點。這些積分和加密資產（代幣）不會由管理層無限期發行，而是針對病人自己激活時具有價值的屬性。

## 採用區塊鏈技術的背後是什麼？

使用集中式數據庫可能會降低可靠性，因為管理員可以隨意改變數據。另一方面，區塊鏈是一個去中心化的系統，其中交易以一系列鏈的形式存儲，使其更難被篡改，並允許一個更可靠和透明的系統。區塊鏈還允許用戶管理自己的價值，使系統更加自主。因此，由區塊鏈技術實現的積分/加密資產（代幣）被視為中心化數據庫的合適替代品。


從推特上看到被激活的測試者正在將他們的代幣發送到我們能看到的其他自我託管錢包，這令人鼓舞。


藥品的目的是通過健康生活的方式發揮功能，創造社會活動的狀態，是實現社會可持續發展的工具，只有合理使用，才有價值。

我們相信，合理使用藥品、患者對自己的身體進行投資，以及一個可持續發展的社會，增加健康的預期壽命，都是有價值的。我們正在開發DrugN，作為一個可以由患者自主使用的工具，以實現這一目標。

從這個角度來看，採用區塊鏈技術的目的是創建一個匿名的醫療保健應用程序，其積分系統讓患者感到自由和愉快，以提高社會的可持續性。

## 在幾個區塊鏈中選擇Symbol的意義何在？
![drugn3.png](/uploads/drugn3_4762dc4d03.png)
在Symbol區塊鏈上，用戶可以通過託管節點參與區塊驗證，並獲得獎勵，這被稱為收穫，即使他們不託管自己的節點，他們也可以通過委託給節點來參與這個過程，這被稱為委託收穫，這就是獎勵的來源。
目前，區塊鏈還存在一些困難，如託管節點、方式賬戶和錢包，尤其是私鑰的管理，但Symbol已經實現了一定程度的去中心化，並且有兩年的工作歷史。同樣重要的是，Symbol區塊鏈的起源NEM也有一個成熟的歷史。

另一方面，也有一種擔憂。其他區塊鏈也是如此，但由於Symbol區塊鏈的原生貨幣XYM是用來支付服務器管理費用的，如果用來支付費用的XYM價格上漲，盈利能力的分歧可能會改變，費用可能無法支付。在這種情況下，可能需要考慮用另一條鏈上的記錄進行遷移，但時間是不可預測的，因此是管理層的擔憂。

然而，Symbol有可能解決這個問題。如上所述，這是一個收穫/委託收穫的區塊驗證過程，以保持鏈的穩定。如果管理層可以主持他們的節點被委託，管理層將受到該區塊驗證的激勵，我們相信這是一個解決方案，將允許我們繼續開展業務，而不會在一定程度上受到成本問題的影響。

而我們目前正在試用自己的服務器來託管我們的節點：https://symbol-01.drugn.life，在提供節點操作的同時增加我們的知識。

在未來，我們希望在Symbol區塊鏈生態系統中為DrugN取得一定的聲譽，如果我們通過授權給我們的節點而得到用戶的支持，這將是令人欣慰的，這是一個具有挑戰性的目標，我們認為。

由於DrugN應用程序使用Symbol，Symbol區塊鏈保持長期使用和活力是非常重要的；當DrugN被使用時，Symbol賬戶會自動創建，增加用戶和交易的數量。

通過使用Symbol區塊鏈，我們可以使用區塊鏈交易來保存藥品的歷史記錄，主持節點的用戶以及收穫者可以獲得包括交易費用的區塊獎勵。為了使用公共區塊鏈，投資者和鏈上技術的粉絲用戶的支持是技術發展本身可持續的必要條件。我們認為支持活動和回饋用戶的方式需要慎重考慮，但DrugN團隊認為Symbol在日本的情況，有很多熱情的用戶和社區，對我們來說是非常有希望的環境。


在未來，我們將圍繞着VC來籌集資金，所以如果我們有很多用戶的支持，有業績，有節點授權等，對我們的活動會有幫助。

請繼續給我們提供關於該應用程序的反饋。反饋可以提高其社會實施的潛力。

謝謝您的聆聽。你的支持對我們意義重大。


[HealthCareGate Co., Ltd.](https://healthcaregate.co.jp/)
[DrugN White Paper](https://drugn.gitbook.io/whitepaper.drugn.life/)
Node : https://symbol-01.drugn.life

Medication traceability DrugN 药品可追溯性 

【Web3遇到藥物治療】藥品追溯應用 "DrugN "被採納為地方政府支持項目

【Web3 meets medication】Medication traceability application “DrugN” adopted for local government support projects

![s-UMUI_TOP2023040101-1024x512.jpg](/uploads/s_UMUI_TOP_2023040101_1024x512_0704cf7c73.jpg)
PaletteLinkOkinawa, LLC, Okinawa Prefecture, Japan, launched a Next Generation NFT Photo Studio "UMUI" service utilising NFTDrive on Friday, 7th April 2023.

"UMUI" means "feelings" in the Okinawan dialect. This service records user's precious "memories" such as travel records, weddings, and family photos permanently with a form of Fully-On-Chain NFT.

This is a remarkable service which is unique to Fully-On-Chain NFT, where data will not be lost even at the end of the usage contract.

**Press Release**
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000001.000113430.html)
[NFT Media](https://nft-media.net/regionalrevitalization/nft-umui/29644/)
[PaletteLinkOkinawa, LLC](https://plo.llc/archives/552)

**Article**
[Ryukyushimpo](https://ryukyushimpo.jp/news/entry-1712707.html)

[UMUI](https://umui.okinawa/)
[PaletteLinkOkinawa, LLC](https://plo.llc/)

PaletteLinkOkinawa, LLC, Okinawa Prefecture, Japan, launched a Next Generation NFT Photo Studio "UMUI" service utilising NFTDrive on Friday, 7th April 2023.

large_s-UMUI_TOP2023040101-1024x512.jpg

medium_s-UMUI_TOP2023040101-1024x512.jpg

small_s-UMUI_TOP2023040101-1024x512.jpg

thumbnail_s-UMUI_TOP2023040101-1024x512.jpg

s-UMUI_TOP2023040101-1024x512.jpg

![s-UMUI_TOP2023040101-1024x512.jpg](/uploads/s_UMUI_TOP_2023040101_1024x512_0704cf7c73.jpg)
沖縄県にある合同会社パレットリンク沖縄は2023年4月7日（金）に、NFTDriveを活用したNFT次世代写真館「UMUI(うむい)」サービスを提供開始しました。
「うむい」とは、沖縄の方言で「想い」という意味をあらわします。旅の記録からウエディング、家族の記念写真など、利用者の大切な「想い出」を恒久的にフルオンチェーンNFTにて記録する。
初期費用以外の月額利用料はかからず、解約したらデータが消えるということもないフルオンチェーンならではの注目サービス。

**プレスリリース**
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000001.000113430.html)
[NFT Media](https://nft-media.net/regionalrevitalization/nft-umui/29644/)
[合同会社パレットリンク沖縄](https://plo.llc/archives/552)

**記事**
[琉球新報](https://ryukyushimpo.jp/news/entry-1712707.html)

[UMUI(うむい)](https://umui.okinawa/)
[合同会社パレットリンク沖縄](https://plo.llc/)

沖縄県にある合同会社パレットリンク沖縄は2023年4月7日（金）に、NFTDriveを活用したNFT次世代写真館「UMUI(うむい)」サービスを提供開始しました。

沖縄の思い出をNFTで残そう「NFT次世代写真館UMUI(うむい)」

This page is a machine translation of the English text. Please contact faunsu https://twitter.com/faunsu19000 or symbol-community.com/community for language proofreading of articles.
![s-UMUI_TOP2023040101-1024x512.jpg](/uploads/s_UMUI_TOP_2023040101_1024x512_0704cf7c73.jpg)
日本冲绳县 PaletteLinkOkinawa, LLC 于2023年4月7日星期五推出了使用 NFTDrive 的下一代 NFT 照片工作室“UMUI”服务。  
“UMUI”在冲绳方言中是“感情”的意思。该服务以Fully-On-Chain NFT的形式永久记录用户珍贵的“记忆”，如旅行记录、婚礼、家庭照片。  
这是Fully-On-Chain NFT独有的一项卓越服务，即使在使用合同结束时数据也不会丢失。  

**新闻稿**
[PRTIMES](https://prtimes.jp/main/html/rd/p/000000001.000113430.html)
[NFT Media](https://nft-media.net/regionalrevitalization/nft-umui/29644/)
[PaletteLinkOkinawa, LLC](https://plo.llc/archives/552)

**報道**
[Ryukyushimpo](https://ryukyushimpo.jp/news/entry-1712707.html)

[UMUI](https://umui.okinawa/)
[PaletteLinkOkinawa, LLC](https://plo.llc/)

日本冲绳县 PaletteLinkOkinawa, LLC 于2023年4月7日星期五推出了使用 NFTDrive 的下一代 NFT 照片工作室“UMUI”服务。  

将您的冲绳回忆保留为 NFT。“次世代NFT影楼UMUI”

Keep your Okinawa memories as an NFT. "Next Generation NFT Photo Studio UMUI"

![OSC.png](/uploads/OSC_2ab00a30f0.png)
[Open Source Festival [OSC2023 Tokyo/Spring]](https://event.ospn.jp/osc2023-spring/)
[NEMTUS](https://nemtus.com)
[Opening Line Inc.](https://www.opening-line.co.jp)

[Announcement by NEMTUS](https://twitter.com/NemtusOfficial/status/1640902871570059264?s=20)

Registration: https://ospn.connpass.com/event/271221/
Date and time: April 1, 2023 10:00 - 16:00(JST)
Place: Tokyo Metropolitan Industrial Trade Centre Taitokan 2-6-5 Hanakawado, Taito-ku, Tokyo

On the day, NEMTUS will exhibit Symbol/NEM-related products and give a brief demonstration, while Opening Line will give a demonstration of Juggle, a file-sharing application that uses the Symbol blockchain.


small_OSC.png

thumbnail_OSC.png

OSC.png

![OSC.png](/uploads/OSC_2ab00a30f0.png)

[Open Source Festival [OSC2023 Tokyo/Spring]](https://event.ospn.jp/osc2023-spring/)
[NEMTUS](https://nemtus.com)
[Opening Line Inc.](https://www.opening-line.co.jp)

[NPO法人NEM技術普及推進会NEMTUSによる告知](https://twitter.com/NemtusOfficial/status/1640902871570059264?s=20)

参加登録: https://ospn.connpass.com/event/271221/
日時：2023年4月1日(土) 10:00～16:00
場所：東京都立産業貿易センター台東館 東京都台東区花川戸2-6-5

当日はNPO法人NEM技術普及推進会NEMTUSはSymbol/NEM関連の展示や簡単なデモなどを、株式会社Opening LineはSymbolブロックチェーンを活用したファイル共有アプリケーションJuggleについてのデモなどを行うそうです。

4/1㈯ に浅草で開催されるオープンソースの祭典【OSC2023 Tokyo/Spring】にNPO法人NEM技術普及推進会NEMTUS、株式会社Opening Lineが出展

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![OSC.png](/uploads/OSC_2ab00a30f0.png)

[Open Source Festival [OSC2023 Tokyo/Spring]](https://event.ospn.jp/osc2023-spring/)
[NEMTUS](https://nemtus.com)
[Opening Line Inc.](https://www.opening-line.co.jp)

[NEMTUS 공지사항](https://twitter.com/NemtusOfficial/status/1640902871570059264?s=20)

등록: https://ospn.connpass.com/event/271221/
날짜 및 시간 2023년 4월 1일 10:00 - 16:00(JST)
장소 : 도쿄도립산업무역센터 다이토관 도쿄도 다이토구 하나카와도 2-6-5

이날 NEMTUS 는 Symbol/NEM 관련 제품을 전시하고 간단한 시연을 진행하며, Opening Line 은  Symbol blockchain 을 활용한 파일 공유 애플리케이션인 Juggle 시연할 예정입니다.


오픈소스 페스티벌 [OSC2023 도쿄/스프링]에 NEMTUS 와 'Opening Line Inc.가 참가합니다

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![OSC.png](/uploads/OSC_2ab00a30f0.png)

[Open Source Festival [OSC2023 Tokyo/Spring]](https://event.ospn.jp/osc2023-spring/)
[NEMTUS](https://nemtus.com)
[Opening Line Inc.](https://www.opening-line.co.jp)

[由NEMTUS发出通知](https://twitter.com/NemtusOfficial/status/1640902871570059264?s=20)

注册: https://ospn.connpass.com/event/271221/
日期和时间： 2023年4月1日 10:00 - 16:00(JST)
地点：东京都工业贸易中心大东馆，东京都台东区花川户2-6-5号

当天，NEMTUS将展出Symbol/NEM相关产品，并进行简短的演示，而Opening Line将演示Juggle，一个使用Symbol区块链的文件共享应用程序。

NEMTUS和Opening Line Inc.将在开源节[OSC2023东京/春季]展出

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![OSC.png](/uploads/OSC_2ab00a30f0.png)

[Open Source Festival [OSC2023 Tokyo/Spring]](https://event.ospn.jp/osc2023-spring/)
[NEMTUS](https://nemtus.com)
[Opening Line Inc.](https://www.opening-line.co.jp)

[由NEMTUS發出通知](https://twitter.com/NemtusOfficial/status/1640902871570059264?s=20)

注冊: https://ospn.connpass.com/event/271221/
日期和時間： 2023年4月1日 10:00 - 16:00(JST)
地點：東京都工業貿易中心大東館，東京都台東區花川戶2-6-5號

當天，NEMTUS將展出Symbol/NEM相關產品，並進行簡短的演示，而Opening Line將演示Juggle，一個使用Symbol區塊鏈的文件共享應用程序。

NEMTUS和Opening Line Inc.將在開源節[OSC2023東京/春季]展出

NEMTUS and Opening Line Inc. will exhibit at the Open Source Festival [OSC2023 Tokyo/Spring]

![HACK+2023.PNG](/uploads/HACK_2023_4373c32876.PNG)

[All 17 entries for the NEMTUS Hackathon HACK+ 2023 are presented to the public](https://nemtus-hackathon.web.app/years/2023/results)

Judging and voting period: 29 March - 4 April 23:59 (JST)

There will also be a community vote, so have a look at the artwork and vote for your favourite.

Results will be announced: 8 April.

Please visit the site below for more details.
[NEMTUS Hackathon HACK+ 2023](https://hackathon-2023.nemtus.com)

Entries

[Entry No. 1](https://nemtus-hackathon.web.app/years/2023/results/5VaBSuV1b1h6zxZyfWFVDQGbFme2)
VoxelTopia
![HACK+ 2023-1.PNG](/uploads/HACK_2023_1_57b15b0ca3.PNG)

[Entry No. 2](https://nemtus-hackathon.web.app/years/2023/results/zYcDOg1x9WYkBux3cws0aVallaO2)
Miruken
![HACK+ 2023-2.JPG](/uploads/HACK_2023_2_47fd546d2e.JPG)


[Entry No. 3](https://nemtus-hackathon.web.app/years/2023/results/in3vkuVqP8bWb28w22sxDwegNpj1)
Symbol Network Graph
![HACK+ 2023-3.PNG](/uploads/HACK_2023_3_931fdf3dc7.PNG)


[Entry No. 4](https://nemtus-hackathon.web.app/years/2023/results/0E9bx8oShxcCv86hDkCI41ixVu73)
MEITEI STRONG-失われた記憶を求めて-
![HACK+ 2023-4.PNG](/uploads/HACK_2023_4_e8a4e48234.PNG)


[Entry No. 5](https://nemtus-hackathon.web.app/years/2023/results/23s3QLBUtxbWwZXiuLjx2e71kGc2)
Symbol Authenticater
![HACK+ 2023-5.JPG](/uploads/HACK_2023_5_4123937abf.JPG)


[Entry No. 6](https://nemtus-hackathon.web.app/years/2023/results/YPuZuVpoExTisbwHlObPXdIFIYJ2)
Symbol Visualization Tool
![HACK+ 2023-6.PNG](/uploads/HACK_2023_6_4a9f18f87c.PNG)


[Entry No. 7](https://nemtus-hackathon.web.app/years/2023/results/qgQoeR7W7MMVXU1x0sbzrFIuSmi1)
Cycle
![HACK+ 2023-7.PNG](/uploads/HACK_2023_7_72d78adf38.PNG)


[Entry No. 8](https://nemtus-hackathon.web.app/years/2023/results/cPkE7CsX35QRttVGsSMhYXXEbVo2)
NewWorldQuest
![HACK+ 2023-8.PNG](/uploads/HACK_2023_8_83cbad81ff.PNG)


[Entry No. 9](https://nemtus-hackathon.web.app/years/2023/results/VhQm4ZryA1PMJdyoNlIcFADsxpo2)
夢　未来　みんなとAIチャット
![HACK+ 2023-9.PNG](/uploads/HACK_2023_9_983aec1348.PNG)


[Entry No. 10](https://nemtus-hackathon.web.app/years/2023/results/9q6oiRTOGfS09NRpFb4i8b3DpHY2)
symbol-firebase-auth
![HACK+ 2023-10.PNG](/uploads/HACK_2023_10_a528993148.PNG)


[Entry No. 11](https://nemtus-hackathon.web.app/years/2023/results/gGB8hUIpj5X7zLVUcceTiaGkKoP2)
ChainGPT
![HACK+ 2023-11.PNG](/uploads/HACK_2023_11_84a1ee4309.PNG)


[Entry No. 12](https://nemtus-hackathon.web.app/years/2023/results/Lz97fvq0wyQsGWmyfdI25OnH1Il1)
Mobile Node powered by Symbol
![HACK+ 2023-12.PNG](/uploads/HACK_2023_12_a8c87e27ce.PNG)


[Entry No. 13](https://nemtus-hackathon.web.app/years/2023/results/bXwKGceSAgUB7Hxoh6sNn0lKwPk2)
Eternal Book Client
![HACK+ 2023-13.PNG](/uploads/HACK_2023_13_5ba40e4ce7.PNG)


[Entry No. 14](https://nemtus-hackathon.web.app/years/2023/results/uNMpxPvKxETdlsLcGgRiFdnJUHs1)
Ventus Wallet
![HACK+ 2023-14.PNG](/uploads/HACK_2023_14_f477002940.PNG)


[Entry No. 15](https://nemtus-hackathon.web.app/years/2023/results/QP30nJs1aEMuZimyFZae7SDcXgm2)
Nagato
![HACK+ 2023-15.PNG](/uploads/HACK_2023_15_1a28ff8f9f.PNG)


[Entry No. 16](https://nemtus-hackathon.web.app/years/2023/results/dS6hXe9uBtSri4gWdGJDEOpp35Z2)
Converter
![HACK+ 2023-16.PNG](/uploads/HACK_2023_16_1c225b4050.PNG)


[Entry No. 17](https://nemtus-hackathon.web.app/years/2023/results/k7UdCBMTdhblYQIkEimA11HETeT2)
ShukinPay
![HACK+ 2023-17.PNG](/uploads/HACK_2023_17_f0d6b1203d.PNG)


![HACK+2023.PNG](/uploads/HACK_2023_4373c32876.PNG)

[NEMTUS Hackathon HACK+ 2023の全17エントリー作品が公開されました。](https://nemtus-hackathon.web.app/years/2023/results)

審査・投票期間：3/29（水）〜4/4（火) 23:59まで

コミュニティ投票も開催されていますので、作品をお楽しみいただき、お気に入りの作品に投票してみてはいかがでしょうか?

結果発表は4/8（土）の予定です。

詳細については、下記サイトをご参照ください。
[NEMTUS Hackathon HACK+ 2023](https://hackathon-2023.nemtus.com)

エントリー作品紹介

[Entry No. 1](https://nemtus-hackathon.web.app/years/2023/results/5VaBSuV1b1h6zxZyfWFVDQGbFme2)
VoxelTopia
![HACK+ 2023-1.PNG](/uploads/HACK_2023_1_57b15b0ca3.PNG)

[Entry No. 2](https://nemtus-hackathon.web.app/years/2023/results/zYcDOg1x9WYkBux3cws0aVallaO2)
Miruken
![HACK+ 2023-2.JPG](/uploads/HACK_2023_2_47fd546d2e.JPG)


[Entry No. 3](https://nemtus-hackathon.web.app/years/2023/results/in3vkuVqP8bWb28w22sxDwegNpj1)
Symbol Network Graph
![HACK+ 2023-3.PNG](/uploads/HACK_2023_3_931fdf3dc7.PNG)


[Entry No. 4](https://nemtus-hackathon.web.app/years/2023/results/0E9bx8oShxcCv86hDkCI41ixVu73)
MEITEI STRONG-失われた記憶を求めて-
![HACK+ 2023-4.PNG](/uploads/HACK_2023_4_e8a4e48234.PNG)


[Entry No. 5](https://nemtus-hackathon.web.app/years/2023/results/23s3QLBUtxbWwZXiuLjx2e71kGc2)
Symbol Authenticater
![HACK+ 2023-5.JPG](/uploads/HACK_2023_5_4123937abf.JPG)


[Entry No. 6](https://nemtus-hackathon.web.app/years/2023/results/YPuZuVpoExTisbwHlObPXdIFIYJ2)
Symbol Visualization Tool
![HACK+ 2023-6.PNG](/uploads/HACK_2023_6_4a9f18f87c.PNG)


[Entry No. 7](https://nemtus-hackathon.web.app/years/2023/results/qgQoeR7W7MMVXU1x0sbzrFIuSmi1)
Cycle
![HACK+ 2023-7.PNG](/uploads/HACK_2023_7_72d78adf38.PNG)


[Entry No. 8](https://nemtus-hackathon.web.app/years/2023/results/cPkE7CsX35QRttVGsSMhYXXEbVo2)
NewWorldQuest
![HACK+ 2023-8.PNG](/uploads/HACK_2023_8_83cbad81ff.PNG)


[Entry No. 9](https://nemtus-hackathon.web.app/years/2023/results/VhQm4ZryA1PMJdyoNlIcFADsxpo2)
夢　未来　みんなとAIチャット
![HACK+ 2023-9.PNG](/uploads/HACK_2023_9_983aec1348.PNG)


[Entry No. 10](https://nemtus-hackathon.web.app/years/2023/results/9q6oiRTOGfS09NRpFb4i8b3DpHY2)
symbol-firebase-auth
![HACK+ 2023-10.PNG](/uploads/HACK_2023_10_a528993148.PNG)


[Entry No. 11](https://nemtus-hackathon.web.app/years/2023/results/gGB8hUIpj5X7zLVUcceTiaGkKoP2)
ChainGPT
![HACK+ 2023-11.PNG](/uploads/HACK_2023_11_84a1ee4309.PNG)


[Entry No. 12](https://nemtus-hackathon.web.app/years/2023/results/Lz97fvq0wyQsGWmyfdI25OnH1Il1)
Mobile Node powered by Symbol
![HACK+ 2023-12.PNG](/uploads/HACK_2023_12_a8c87e27ce.PNG)


[Entry No. 13](https://nemtus-hackathon.web.app/years/2023/results/bXwKGceSAgUB7Hxoh6sNn0lKwPk2)
Eternal Book Client
![HACK+ 2023-13.PNG](/uploads/HACK_2023_13_5ba40e4ce7.PNG)


[Entry No. 14](https://nemtus-hackathon.web.app/years/2023/results/uNMpxPvKxETdlsLcGgRiFdnJUHs1)
Ventus Wallet
![HACK+ 2023-14.PNG](/uploads/HACK_2023_14_f477002940.PNG)


[Entry No. 15](https://nemtus-hackathon.web.app/years/2023/results/QP30nJs1aEMuZimyFZae7SDcXgm2)
Nagato
![HACK+ 2023-15.PNG](/uploads/HACK_2023_15_1a28ff8f9f.PNG)


[Entry No. 16](https://nemtus-hackathon.web.app/years/2023/results/dS6hXe9uBtSri4gWdGJDEOpp35Z2)
Converter
![HACK+ 2023-16.PNG](/uploads/HACK_2023_16_1c225b4050.PNG)


[Entry No. 17](https://nemtus-hackathon.web.app/years/2023/results/k7UdCBMTdhblYQIkEimA11HETeT2)
ShukinPay
![HACK+ 2023-17.PNG](/uploads/HACK_2023_17_f0d6b1203d.PNG)


NEMTUS Hackathon HACK+ 2023の全17エントリー作品が公開されました。

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![HACK+2023.PNG](/uploads/HACK_2023_4373c32876.PNG)

[NEMTUS Hackathon HACK+2023 에 출품된 17개 작품이 모두 공개됩니다.](https://nemtus-hackathon.web.app/years/2023/results)

심사 및 투표 기간: 3월 29일 - 4월 4일 23:59 (JST)

커뮤니티 투표도 진행될 예정이니 작품을 살펴보고 가장 마음에 드는 작품에 투표해 주세요.

결과 발표 예정일: 4월 8일.

자세한 내용은 아래 사이트를 참조하세요.
[NEMTUS Hackathon HACK+ 2023](https://hackathon-2023.nemtus.com)

항목

[Entry No. 1](https://nemtus-hackathon.web.app/years/2023/results/5VaBSuV1b1h6zxZyfWFVDQGbFme2)
VoxelTopia
![HACK+ 2023-1.PNG](/uploads/HACK_2023_1_57b15b0ca3.PNG)

[Entry No. 2](https://nemtus-hackathon.web.app/years/2023/results/zYcDOg1x9WYkBux3cws0aVallaO2)
Miruken
![HACK+ 2023-2.JPG](/uploads/HACK_2023_2_47fd546d2e.JPG)


[Entry No. 3](https://nemtus-hackathon.web.app/years/2023/results/in3vkuVqP8bWb28w22sxDwegNpj1)
Symbol Network Graph
![HACK+ 2023-3.PNG](/uploads/HACK_2023_3_931fdf3dc7.PNG)


[Entry No. 4](https://nemtus-hackathon.web.app/years/2023/results/0E9bx8oShxcCv86hDkCI41ixVu73)
MEITEI STRONG-失われた記憶を求めて-
![HACK+ 2023-4.PNG](/uploads/HACK_2023_4_e8a4e48234.PNG)


[Entry No. 5](https://nemtus-hackathon.web.app/years/2023/results/23s3QLBUtxbWwZXiuLjx2e71kGc2)
Symbol Authenticater
![HACK+ 2023-5.JPG](/uploads/HACK_2023_5_4123937abf.JPG)


[Entry No. 6](https://nemtus-hackathon.web.app/years/2023/results/YPuZuVpoExTisbwHlObPXdIFIYJ2)
Symbol Visualization Tool
![HACK+ 2023-6.PNG](/uploads/HACK_2023_6_4a9f18f87c.PNG)


[Entry No. 7](https://nemtus-hackathon.web.app/years/2023/results/qgQoeR7W7MMVXU1x0sbzrFIuSmi1)
Cycle
![HACK+ 2023-7.PNG](/uploads/HACK_2023_7_72d78adf38.PNG)


[Entry No. 8](https://nemtus-hackathon.web.app/years/2023/results/cPkE7CsX35QRttVGsSMhYXXEbVo2)
NewWorldQuest
![HACK+ 2023-8.PNG](/uploads/HACK_2023_8_83cbad81ff.PNG)


[Entry No. 9](https://nemtus-hackathon.web.app/years/2023/results/VhQm4ZryA1PMJdyoNlIcFADsxpo2)
夢　未来　みんなとAIチャット
![HACK+ 2023-9.PNG](/uploads/HACK_2023_9_983aec1348.PNG)


[Entry No. 10](https://nemtus-hackathon.web.app/years/2023/results/9q6oiRTOGfS09NRpFb4i8b3DpHY2)
symbol-firebase-auth
![HACK+ 2023-10.PNG](/uploads/HACK_2023_10_a528993148.PNG)


[Entry No. 11](https://nemtus-hackathon.web.app/years/2023/results/gGB8hUIpj5X7zLVUcceTiaGkKoP2)
ChainGPT
![HACK+ 2023-11.PNG](/uploads/HACK_2023_11_84a1ee4309.PNG)


[Entry No. 12](https://nemtus-hackathon.web.app/years/2023/results/Lz97fvq0wyQsGWmyfdI25OnH1Il1)
Mobile Node powered by Symbol
![HACK+ 2023-12.PNG](/uploads/HACK_2023_12_a8c87e27ce.PNG)


[Entry No. 13](https://nemtus-hackathon.web.app/years/2023/results/bXwKGceSAgUB7Hxoh6sNn0lKwPk2)
Eternal Book Client
![HACK+ 2023-13.PNG](/uploads/HACK_2023_13_5ba40e4ce7.PNG)


[Entry No. 14](https://nemtus-hackathon.web.app/years/2023/results/uNMpxPvKxETdlsLcGgRiFdnJUHs1)
Ventus Wallet
![HACK+ 2023-14.PNG](/uploads/HACK_2023_14_f477002940.PNG)


[Entry No. 15](https://nemtus-hackathon.web.app/years/2023/results/QP30nJs1aEMuZimyFZae7SDcXgm2)
Nagato
![HACK+ 2023-15.PNG](/uploads/HACK_2023_15_1a28ff8f9f.PNG)


[Entry No. 16](https://nemtus-hackathon.web.app/years/2023/results/dS6hXe9uBtSri4gWdGJDEOpp35Z2)
Converter
![HACK+ 2023-16.PNG](/uploads/HACK_2023_16_1c225b4050.PNG)


[Entry No. 17](https://nemtus-hackathon.web.app/years/2023/results/k7UdCBMTdhblYQIkEimA11HETeT2)
ShukinPay
![HACK+ 2023-17.PNG](/uploads/HACK_2023_17_f0d6b1203d.PNG)


NEMTUS Hackathon HACK+2023 에 출품된 17개 작품이 모두 공개됩니다.

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![HACK+2023.PNG](/uploads/HACK_2023_4373c32876.PNG)

[NEMTUS Hackathon HACK+2023的所有17份参赛作品现在已经公开发布。](https://nemtus-hackathon.web.app/years/2023/results)

评审和投票时间：3月29日-4月4日23:59（日本时间）。

此外，还将进行社区投票，所以请看一下作品，为你最喜欢的作品投票。

结果将于4月8日公布。

请访问以下网站了解更多细节。
[NEMTUS Hackathon HACK+ 2023](https://hackathon-2023.nemtus.com)

栏目介绍

[Entry No. 1](https://nemtus-hackathon.web.app/years/2023/results/5VaBSuV1b1h6zxZyfWFVDQGbFme2)
VoxelTopia
![HACK+ 2023-1.PNG](/uploads/HACK_2023_1_57b15b0ca3.PNG)

[Entry No. 2](https://nemtus-hackathon.web.app/years/2023/results/zYcDOg1x9WYkBux3cws0aVallaO2)
Miruken
![HACK+ 2023-2.JPG](/uploads/HACK_2023_2_47fd546d2e.JPG)


[Entry No. 3](https://nemtus-hackathon.web.app/years/2023/results/in3vkuVqP8bWb28w22sxDwegNpj1)
Symbol Network Graph
![HACK+ 2023-3.PNG](/uploads/HACK_2023_3_931fdf3dc7.PNG)


[Entry No. 4](https://nemtus-hackathon.web.app/years/2023/results/0E9bx8oShxcCv86hDkCI41ixVu73)
MEITEI STRONG-失われた記憶を求めて-
![HACK+ 2023-4.PNG](/uploads/HACK_2023_4_e8a4e48234.PNG)


[Entry No. 5](https://nemtus-hackathon.web.app/years/2023/results/23s3QLBUtxbWwZXiuLjx2e71kGc2)
Symbol Authenticater
![HACK+ 2023-5.JPG](/uploads/HACK_2023_5_4123937abf.JPG)


[Entry No. 6](https://nemtus-hackathon.web.app/years/2023/results/YPuZuVpoExTisbwHlObPXdIFIYJ2)
Symbol Visualization Tool
![HACK+ 2023-6.PNG](/uploads/HACK_2023_6_4a9f18f87c.PNG)


[Entry No. 7](https://nemtus-hackathon.web.app/years/2023/results/qgQoeR7W7MMVXU1x0sbzrFIuSmi1)
Cycle
![HACK+ 2023-7.PNG](/uploads/HACK_2023_7_72d78adf38.PNG)


[Entry No. 8](https://nemtus-hackathon.web.app/years/2023/results/cPkE7CsX35QRttVGsSMhYXXEbVo2)
NewWorldQuest
![HACK+ 2023-8.PNG](/uploads/HACK_2023_8_83cbad81ff.PNG)


[Entry No. 9](https://nemtus-hackathon.web.app/years/2023/results/VhQm4ZryA1PMJdyoNlIcFADsxpo2)
夢　未来　みんなとAIチャット
![HACK+ 2023-9.PNG](/uploads/HACK_2023_9_983aec1348.PNG)


[Entry No. 10](https://nemtus-hackathon.web.app/years/2023/results/9q6oiRTOGfS09NRpFb4i8b3DpHY2)
symbol-firebase-auth
![HACK+ 2023-10.PNG](/uploads/HACK_2023_10_a528993148.PNG)


[Entry No. 11](https://nemtus-hackathon.web.app/years/2023/results/gGB8hUIpj5X7zLVUcceTiaGkKoP2)
ChainGPT
![HACK+ 2023-11.PNG](/uploads/HACK_2023_11_84a1ee4309.PNG)


[Entry No. 12](https://nemtus-hackathon.web.app/years/2023/results/Lz97fvq0wyQsGWmyfdI25OnH1Il1)
Mobile Node powered by Symbol
![HACK+ 2023-12.PNG](/uploads/HACK_2023_12_a8c87e27ce.PNG)


[Entry No. 13](https://nemtus-hackathon.web.app/years/2023/results/bXwKGceSAgUB7Hxoh6sNn0lKwPk2)
Eternal Book Client
![HACK+ 2023-13.PNG](/uploads/HACK_2023_13_5ba40e4ce7.PNG)


[Entry No. 14](https://nemtus-hackathon.web.app/years/2023/results/uNMpxPvKxETdlsLcGgRiFdnJUHs1)
Ventus Wallet
![HACK+ 2023-14.PNG](/uploads/HACK_2023_14_f477002940.PNG)


[Entry No. 15](https://nemtus-hackathon.web.app/years/2023/results/QP30nJs1aEMuZimyFZae7SDcXgm2)
Nagato
![HACK+ 2023-15.PNG](/uploads/HACK_2023_15_1a28ff8f9f.PNG)


[Entry No. 16](https://nemtus-hackathon.web.app/years/2023/results/dS6hXe9uBtSri4gWdGJDEOpp35Z2)
Converter
![HACK+ 2023-16.PNG](/uploads/HACK_2023_16_1c225b4050.PNG)


[Entry No. 17](https://nemtus-hackathon.web.app/years/2023/results/k7UdCBMTdhblYQIkEimA11HETeT2)
ShukinPay
![HACK+ 2023-17.PNG](/uploads/HACK_2023_17_f0d6b1203d.PNG)


NEMTUS Hackathon HACK+2023的所有17份参赛作品现在已经公开发布。

This page is a machine translation of the English text. Please contact `faunsu https://twitter.com/faunsu19000` or `symbol-community.com/community` for language proofreading of articles.

![HACK+2023.PNG](/uploads/HACK_2023_4373c32876.PNG)

[NEMTUS Hackathon HACK+2023的所有17份參賽作品現在已經公開發布。](https://nemtus-hackathon.web.app/years/2023/results)

評審和投票時間：3月29日-4月4日23:59（日本時間）。

此外，還將進行社區投票，所以請看一下作品，為你最喜歡的作品投票。

結果將於4月8日公布。

請訪問以下網站了解更多細節。
[NEMTUS Hackathon HACK+ 2023](https://hackathon-2023.nemtus.com)

欄目介紹

[Entry No. 1](https://nemtus-hackathon.web.app/years/2023/results/5VaBSuV1b1h6zxZyfWFVDQGbFme2)
VoxelTopia
![HACK+ 2023-1.PNG](/uploads/HACK_2023_1_57b15b0ca3.PNG)

[Entry No. 2](https://nemtus-hackathon.web.app/years/2023/results/zYcDOg1x9WYkBux3cws0aVallaO2)
Miruken
![HACK+ 2023-2.JPG](/uploads/HACK_2023_2_47fd546d2e.JPG)


[Entry No. 3](https://nemtus-hackathon.web.app/years/2023/results/in3vkuVqP8bWb28w22sxDwegNpj1)
Symbol Network Graph
![HACK+ 2023-3.PNG](/uploads/HACK_2023_3_931fdf3dc7.PNG)


[Entry No. 4](https://nemtus-hackathon.web.app/years/2023/results/0E9bx8oShxcCv86hDkCI41ixVu73)
MEITEI STRONG-失われた記憶を求めて-
![HACK+ 2023-4.PNG](/uploads/HACK_2023_4_e8a4e48234.PNG)


[Entry No. 5](https://nemtus-hackathon.web.app/years/2023/results/23s3QLBUtxbWwZXiuLjx2e71kGc2)
Symbol Authenticater
![HACK+ 2023-5.JPG](/uploads/HACK_2023_5_4123937abf.JPG)


[Entry No. 6](https://nemtus-hackathon.web.app/years/2023/results/YPuZuVpoExTisbwHlObPXdIFIYJ2)
Symbol Visualization Tool
![HACK+ 2023-6.PNG](/uploads/HACK_2023_6_4a9f18f87c.PNG)


[Entry No. 7](https://nemtus-hackathon.web.app/years/2023/results/qgQoeR7W7MMVXU1x0sbzrFIuSmi1)
Cycle
![HACK+ 2023-7.PNG](/uploads/HACK_2023_7_72d78adf38.PNG)


[Entry No. 8](https://nemtus-hackathon.web.app/years/2023/results/cPkE7CsX35QRttVGsSMhYXXEbVo2)
NewWorldQuest
![HACK+ 2023-8.PNG](/uploads/HACK_2023_8_83cbad81ff.PNG)


[Entry No. 9](https://nemtus-hackathon.web.app/years/2023/results/VhQm4ZryA1PMJdyoNlIcFADsxpo2)
夢　未来　みんなとAIチャット
![HACK+ 2023-9.PNG](/uploads/HACK_2023_9_983aec1348.PNG)


[Entry No. 10](https://nemtus-hackathon.web.app/years/2023/results/9q6oiRTOGfS09NRpFb4i8b3DpHY2)
symbol-firebase-auth
![HACK+ 2023-10.PNG](/uploads/HACK_2023_10_a528993148.PNG)


[Entry No. 11](https://nemtus-hackathon.web.app/years/2023/results/gGB8hUIpj5X7zLVUcceTiaGkKoP2)
ChainGPT
![HACK+ 2023-11.PNG](/uploads/HACK_2023_11_84a1ee4309.PNG)


[Entry No. 12](https://nemtus-hackathon.web.app/years/2023/results/Lz97fvq0wyQsGWmyfdI25OnH1Il1)
Mobile Node powered by Symbol
![HACK+ 2023-12.PNG](/uploads/HACK_2023_12_a8c87e27ce.PNG)


[Entry No. 13](https://nemtus-hackathon.web.app/years/2023/results/bXwKGceSAgUB7Hxoh6sNn0lKwPk2)
Eternal Book Client
![HACK+ 2023-13.PNG](/uploads/HACK_2023_13_5ba40e4ce7.PNG)


[Entry No. 14](https://nemtus-hackathon.web.app/years/2023/results/uNMpxPvKxETdlsLcGgRiFdnJUHs1)
Ventus Wallet
![HACK+ 2023-14.PNG](/uploads/HACK_2023_14_f477002940.PNG)


[Entry No. 15](https://nemtus-hackathon.web.app/years/2023/results/QP30nJs1aEMuZimyFZae7SDcXgm2)
Nagato
![HACK+ 2023-15.PNG](/uploads/HACK_2023_15_1a28ff8f9f.PNG)


[Entry No. 16](https://nemtus-hackathon.web.app/years/2023/results/dS6hXe9uBtSri4gWdGJDEOpp35Z2)
Converter
![HACK+ 2023-16.PNG](/uploads/HACK_2023_16_1c225b4050.PNG)


[Entry No. 17](https://nemtus-hackathon.web.app/years/2023/results/k7UdCBMTdhblYQIkEimA11HETeT2)
ShukinPay
![HACK+ 2023-17.PNG](/uploads/HACK_2023_17_f0d6b1203d.PNG)


NEMTUS Hackathon HACK+2023的所有17份參賽作品現在已經公開發布。

All 17 entries for the NEMTUS Hackathon HACK+ 2023 are presented to the public.

![2023 02 27 NEM Stall Post Mortem](/uploads/2023_02_27_NEM_Stall_Post_Mortem_544cb72628.png)

## Observation

After the production of block 4129631, block production on the NEM network slowed to a crawl. This situation was instigated by an unexpected transaction entering the Unconfirmed Transactions cache. When this transaction expired, block production went back to normal.

We have identified the makeup of the unexpected transaction and how it entered the Unconfirmed Transactions cache.

A multisig account configured with 1-of-2 multisig sent two conflicting transactaions. Assume that the two cosigners are named A and B and the multisig account is named M.

## Root Cause Analysis

The following sequence of events occured:

1. M sends a multisig transaction MT with an inner transaction - X - signed by A

1. The multisig transaction gets committed to the chain and TransactionHashesObserver (running as part of BlockTransactionFactory) adds both H(MT), H(X) to HashTransactionsCache

   ```java
   public void notify(final TransactionHashesNotification notification, final BlockNotificationContext context) {
   if (NotificationTrigger.Execute == context.getTrigger()) {
   	this.transactionHashCache.putAll(notification.getPairs());
   } 
   ...
   ```

   Importantly, when the `TransactionsHashesNotification` is created, `streamDefault` is used, which expands to both outer and inner transactions:

   ```java
   protected void notifyTransactionHashes() {
   	final List<HashMetaDataPair> pairs = BlockExtensions.streamDefault(this.block)
   			.map(t -> new HashMetaDataPair(HashUtils.calculateHash(t), new HashMetaData(this.block.getHeight(), t.getTimeStamp())))
   			.collect(Collectors.toList());
   	this.observer.notify(new TransactionHashesNotification(pairs));
   }
   
   ```

1. M sends a multisig transaction MT' with the **SAME** inner transaction X signed by B

1. `BatchUniqueHashTransactionValidator` checks that H(MT') is not in HashTransactionsCache, so it gets added to UnconfirmedTransactionsCache ✅ 

   ```java
   public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
           ...
   	final List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
   			.map(HashUtils::calculateHash).collect(Collectors.toList());
   
   	return this.validate(hashes);
   }
   
   ```

   Importantly, `pair.getTransactions()` returns ` Collection<Transaction>`, which only contains outer transactions. As a result, H(MT') != H(MT) is checked but H(X) is not checked.

1. MT' gets selected for a block by the harvester. `BlockUniqueHashTransactionValidator` has the same logic as `BatchUniqueHashTransactionValidator`, so only the hash of the outer MT' is checked. As a result, the transaction is included in the harvested block ✅ 

   ```java
   public ValidationResult validate(final Block 
           ...
   	final List<Hash> hashes = block.getTransactions().stream().map(HashUtils::calculateHash).collect(Collectors.toList());
   	return this.transactionHashCache.anyHashExists(hashes) ? ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
   }
   ```

1. When the newly harvested block - containing MT' -  is processed, `TransactionHashesObserver` attempts to add both H(MT') and H(X) to `HashTransactionsCache` during part of the block processing that makes state changes. This fails because H(X) is already present in the `UnconfirmedTransactionsCache`, so the harvested block gets rejected  🛑

1. Go to step 5 until H(MT') expires out of the `UnconfirmedTransactionsCache`

![2023 02 27 NEM Stall Post Mortem](/uploads/2023_02_27_NEM_Stall_Post_Mortem_544cb72628.png)

## Fix

The fix is to update both of the unique hash transaction validators to check both outer and inner transactions hashes. This can be done simply by using `TransactionExtensions.streamDefault()`.

### BatchUniqueHashTransactionValidator

The addition of `TransactionExtensions.streamDefault` will prevent MT' (or similar) from getting added to the `UnconfirmedTransactionsCache.

```java
public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
    if (groupedTransactions.isEmpty()) {
        return ValidationResult.SUCCESS;
    }

    final List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
            .flatMap(transaction -> TransactionExtensions.streamDefault(transaction)).map(HashUtils::calculateHash)
            .collect(Collectors.toList());
    return this.validate(hashes);
}
```

### BlockUniqueHashTransactionValidator

The addition of `TransactionExtensions.streamDefault` will prevent MT' (or similar) from getting added to a newly harvested block.

```java
public ValidationResult validate(final Block block) {
    if (block.getTransactions().isEmpty()) {
        return ValidationResult.SUCCESS;
    }

    final List<Hash> hashes = block.getTransactions().stream().flatMap(transaction -> TransactionExtensions.streamDefault(transaction))
            .map(HashUtils::calculateHash).collect(Collectors.toList());
    return this.transactionHashCache.anyHashExists(hashes) ? ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
}
```


After the production of block 4129631, block production on the NEM network slowed to a crawl.

large_post-mortem.png

medium_post-mortem.png

small_post-mortem.png

thumbnail_post-mortem.png

post-mortem.png

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 観測結果

ブロック 4129631 の生成後に、NEMネットワークにおけるブロック生成は鈍化し、遅延しました。この状況は、予期せぬトランザクションがUnconfirmed Transactionsキャッシュに入ったことをきっかけに発生いたしました。その後、このトランザクションが期限切れになると、ブロックの生成は通常どおりへと戻りました。

確認された予期せぬトランザクションの構成と、Unconfirmed Transactionsキャッシュに入った経緯は次の通りです。

1-of-2マルチシグで設定されたマルチシグアカウントが、2つの矛盾するトランザクションを送信しました。ここでは、その連署者をA、Bとし、マルチシグアカウントをMとします。

## 根本的な原因の解析

発生の流れは次の通りです:

1. アカウントMが、 署名者Aによって署名された内部トランザクション- X -を内包するマルチシグトランザクションMTを送信

2. そのマルチシグトランザクションはチェーンにコミットされ、（BlockTransactionFactoryの一部として実行される）TransactionHashesObserverが、H(MT)と H(X) をHashTransactionsCacheに追加

    ```java
    public void notify(final TransactionHashesNotification notification, final BlockNotificationContext context) {
	if (NotificationTrigger.Execute == context.getTrigger()) {
		this.transactionHashCache.putAll(notification.getPairs());
	} 
    ...
    ```
    重要な点は、`TransactionsHashesNotification` が作成された時、 `streamDefault` が使用され、 内部及び外部トランザクションに拡張されたことです:
    ```java
	protected void notifyTransactionHashes() {
		final List<HashMetaDataPair> pairs = BlockExtensions.streamDefault(this.block)
				.map(t -> new HashMetaDataPair(HashUtils.calculateHash(t), new HashMetaData(this.block.getHeight(), t.getTimeStamp())))
				.collect(Collectors.toList());
		this.observer.notify(new TransactionHashesNotification(pairs));
	}

    ```

3. アカウントMは、連署者Bが署名した**同じ**内部トランザクションXを持つマルチシグトランザクションMT'を送信します

4. `BatchUniqueHashTransactionValidator` は、H(MT')がHashTransactionsCacheにないことをチェックするので、それはUnconfirmedTransactionsCacheに追加されます ✅ 
    ```java
	public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
            ...
		final List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
				.map(HashUtils::calculateHash).collect(Collectors.toList());

		return this.validate(hashes);
	}

    ```
    重要な点は、 `pair.getTransactions()` が 外部トランザクションしか含まれていない` Collection<Transaction>`を返すことです。 結果として、 H(MT') != H(MT) はチェックされますが、 H(X) はチェックされません。

5. MT' はハーベスターによってブロックに選択されます。`BlockUniqueHashTransactionValidator` は、`BatchUniqueHashTransactionValidator`と同じロジックを持つため、外部トランザクション MT'のハッシュのみがチェックされます。 その結果、トランザクションはハーベストされたブロックに含まれます。 ✅ 
    ```java
	public ValidationResult validate(final Block 
            ...
		final List<Hash> hashes = block.getTransactions().stream().map(HashUtils::calculateHash).collect(Collectors.toList());
		return this.transactionHashCache.anyHashExists(hashes) ? ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
	}
    ```

6. MT'を含む新しくハーベストされたブロックが処理される時、`TransactionHashesObserver` は、状態の変更を行うブロック処理の一部で、H(MT') H(X)の両方を`HashTransactionsCache`に登録しようとします。ですが既に H(X) は `UnconfirmedTransactionsCache`に存在するために失敗し、ハーベストされたブロックは拒否されます。 🛑

7. H(MT') が失効するまで、`UnconfirmedTransactionsCache`ステップ5へ進みます。

![2023 02 27 NEM Stall Post Mortem](/uploads/2023_02_27_NEM_Stall_Post_Mortem_544cb72628.png)

## 修正

修正につきましては、一意のハッシュトランザクションバリデーターのどちらもを、外部トランザクションと内部トランザクションの両方をチェックするようにすることです。このことは、単に`TransactionExtensions.streamDefault()`を用いることで解決されます。

### BatchUniqueHashTransactionValidator

`TransactionExtensions.streamDefault` を追加することで、MT' (または類似のもの) が `UnconfirmedTransactionsCache への追加を防ぐことができます。

```java
public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
    if (groupedTransactions.isEmpty()) {
        return ValidationResult.SUCCESS;
    }

    final List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
            .flatMap(transaction -> TransactionExtensions.streamDefault(transaction)).map(HashUtils::calculateHash)
            .collect(Collectors.toList());
    return this.validate(hashes);
}
```
### BlockUniqueHashTransactionValidator

`TransactionExtensions.streamDefault` を追加することで、MT' (または類似のもの) が新たにハーベストされるブロックへの追加を防ぐことができます。

```java
public ValidationResult validate(final Block block) {
    if (block.getTransactions().isEmpty()) {
        return ValidationResult.SUCCESS;
    }

    final List<Hash> hashes = block.getTransactions().stream().flatMap(transaction -> TransactionExtensions.streamDefault(transaction))
            .map(HashUtils::calculateHash).collect(Collectors.toList());
    return this.transactionHashCache.anyHashExists(hashes) ? ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
}
```

ブロック 4129631 の生成後に、NEMネットワークにおけるブロック生成は鈍化し、遅延しました。

2023-02-27  事後報告

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 관찰

블록 4129631이 생성된 후, NEM 네트워크의 블록 생성 속도가 느려졌습니다. 이러한 상황은 미확인 트랜잭션 캐시에 예기치 않은 트랜잭션이 들어와서 발생했습니다. 이 트랜잭션이 만료되자 블록 생성은 정상으로 돌아갔습니다.

저희는 예기치 않은 트랜잭션의 구성과 미확인 트랜잭션 캐시에 들어간 경위를 확인했습니다.

2대1 다중 서명으로 구성된 다중 서명 계정이 두 개의 상충되는 트랜잭션을 보냈습니다. 두 명의 공동 서명자의 이름은 A와 B이고 다중 서명 계정의 이름은 M이라고 가정합니다.

## 근본 원인 분석

다음과 같은 일련의 이벤트가 발생했습니다:

1. M이 A가 서명한 내부 트랜잭션 X가 포함된 다중서명 트랜잭션 MT를 보냅니다.

1. 다중서명 트랜잭션이 체인에 커밋되고 (블록트랜잭션팩토리의 일부로 실행되는) TransactionHashesObserver가 H(MT), H(X)를 모두 해시트랜잭션캐시에 추가합니다.

   ```java
   public void notify(final TransactionHashesNotification notification, final BlockNotificationContext context) {
   if (NotificationTrigger.Execute == context.getTrigger()) {
   	this.transactionHashCache.putAll(notification.getPairs());
   } 
   ...
   ```

   중요한 것은 `TransactionsHashesNotification`이 생성될 때 외부 트랜잭션과 내부 트랜잭션 모두로 확장되는 `streamDefault`가 사용된다는 점입니다:

   ```java
   protected void notifyTransactionHashes() {
   	final List<HashMetaDataPair> pairs = BlockExtensions.streamDefault(this.block)
   			.map(t -> new HashMetaDataPair(HashUtils.calculateHash(t), new HashMetaData(this.block.getHeight(), t.getTimeStamp())))))
   			.collect(Collectors.toList());
   	this.observer.notify(새로운 트랜잭션해시알림(쌍));
   }
   
   ```

1. M은 B가 서명한 **SAME** 내부 트랜잭션 X와 함께 다중서명 트랜잭션 MT'를 보냅니다.

1. `BatchUniqueHashTransactionValidator`는 H(MT')가 해시트랜잭션캐시에 없는지 확인하여 UnconfirmedTransactionsCache에 추가합니다 ✅. 

   ```java
   public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
           ...
   	final List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
   			.map(HashUtils::calculateHash).collect(Collectors.toList());
   
   	return this.validate(hashes);
   }
   
   ```

   중요한 것은 `pair.getTransactions()`가 외부 트랜잭션만 포함하는 `Collection<Transaction>`을 반환한다는 점입니다. 결과적으로 H(MT') != H(MT)는 확인되지만 H(X)는 확인되지 않습니다.

1. MT'가 하베스터에 의해 블록으로 선택됩니다. BlockUniqueHashTransactionValidator`는 `BatchUniqueHashTransactionValidator`와 동일한 로직을 가지고 있기 때문에 외부의 MT'의 해시만 확인합니다. 결과적으로 해당 트랜잭션은 수집된 블록에 ✅ 

   ```java
   public ValidationResult validate(final Block 
           ...
   	final List<Hash> hashes = block.getTransactions().stream().map(HashUtils::calculateHash).collect(Collectors.toList());
   	return this.transactionHashCache.anyHashExists(hashes) ? ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
   }
   ```

1. 새로 수집된 블록(MT'를 포함)이 처리될 때, `TransactionHashesObserver`는 상태를 변경하는 블록 처리의 일부에서 `HashTransactionsCache`에 H(MT'와 H(X)를 모두 추가하려고 시도합니다. H(X)가 이미 `UnconfirmedTransactionsCache`에 존재하기 때문에 실패하고, 수집된 블록은 거부됩니다 🛑.

1. 5단계로 이동하여 `UnconfirmedTransactionsCache`에서 H(MT')가 만료될 때까지 기다립니다.

![2023 02 27 NEM Stall Post Mortem](/uploads/2023_02_27_NEM_Stall_Post_Mortem_544cb72628.png)

## 수정

수정 사항은 외부 및 내부 트랜잭션 해시를 모두 확인하도록 두 고유 해시 트랜잭션 유효성 검사기를 모두 업데이트하는 것입니다. 트랜잭션 유효성 검사기는 `TransactionExtensions.streamDefault()`를 사용하여 간단히 수행할 수 있습니다.

### 배치유니크해시 트랜잭션 검증자

트랜잭션 익스텐션에 `TransactionExtensions.streamDefault`를 추가하면 MT'(또는 이와 유사한)가 `UnconfirmedTransactionsCache`에 추가되는 것을 방지할 수 있습니다.

```java
public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
    if (groupedTransactions.isEmpty()) {
        ValidationResult.SUCCESS를 반환합니다;
    }

    final List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
            .flatMap(트랜잭션 -> 트랜잭션익스텐션.streamDefault(트랜잭션)).map(해시유틸스::계산해시)
            .collect(Collectors.toList());
    return this.validate(hashes);
}
```

### 블록유니크해시 트랜잭션 검증자

TransactionExtensions.streamDefault`를 추가하면 새로 수집된 블록에 MT(또는 이와 유사한)가 추가되는 것을 방지할 수 있습니다.

```java
public ValidationResult validate(final Block 블록) {
    if (block.getTransactions().isEmpty()) {
        ValidationResult.SUCCESS를 반환합니다;
    }

    final List<Hash> hashes = block.getTransactions().stream().flatMap(transaction -> TransactionExtensions.streamDefault(transaction))
            .map(HashUtils::calculateHash).collect(Collect

Translated with www.DeepL.com/Translator (free version)

블록 4129631이 생성된 후, NEM 네트워크의 블록 생성 속도가 느려졌습니다.

2023년 2월 27일 NEM 스톨 포스트모템

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 观察

在区块 4129631 生成后，NEM 网络上的区块生成速度变得缓慢。 这种情况是由进入未确认交易缓存的意外交易引起的。 当这笔交易到期时，区块生产恢复正常。

我们已经确定了意外交易的构成以及它是如何进入未确认交易缓存的。

配置了 1-of-2 多重签名的多重签名帐户发送了两个相互冲突的交易。 假设两个共同签名者名为 A 和 B，多重签名账户名为 M。

## 根本原因分析

发生了以下事件序列：

1. M 发送一个多重签名交易 MT，其中包含一个内部交易 - X - 由 A 签名

1. 多重签名交易提交到链上，TransactionHashesObserver（作为 BlockTransactionFactory 的一部分运行）将 H(MT)、H(X) 添加到 HashTransactionsCache

    ```java
    public void notify(final TransactionHashesNotification notification, final BlockNotificationContext context) {
    如果 (NotificationTrigger.Execute == context.getTrigger()) {
    this.transactionHashCache.putAll(notification.getPairs());
    }
    ...
    ```

    重要的是，当创建 TransactionsHashesNotification 时，会使用 streamDefault，它会扩展到外部和内部交易：

    ```java
    protected void notifyTransactionHashes() {
    final List<HashMetaDataPair> 对 = BlockExtensions.streamDefault(this.block)
    .map(t -> new HashMetaDataPair(HashUtils.calculateHash(t), new HashMetaData(this.block.getHeight(), t.getTimeStamp())))
    .collect(Collectors.toList());
    this.observer.notify(new TransactionHashesNotification(pairs));
    }
   
    ```

1. M 发送一个多重签名交易 MT'，其中包含由 B 签名的 **SAME** 内部交易 X

1. `BatchUniqueHashTransactionValidator` 检查 H(MT') 不在 HashTransactionsCache 中，因此它被添加到 UnconfirmedTransactionsCache ✅

    ```java
    public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
            ...
    最终 List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
    .map(HashUtils::calculateHash).collect(Collectors.toList());
   
    返回 this.validate(hashes);
    }
   
    ```

    重要的是，`pair.getTransactions()` 返回仅包含外部交易的 `Collection<Transaction>`。 结果，检查了 H(MT') != H(MT) 但未检查 H(X)。

1. MT' 被收割机选为一个区块。 `BlockUniqueHashTransactionValidator` 和`BatchUniqueHashTransactionValidator` 的逻辑是一样的，所以只检查外层 MT 的 hash。 结果，交易被包含在收获的区块中 ✅

    ```java
    公共 ValidationResult 验证（最终块
            ...
    final List<Hash> hashes = block.getTransactions().stream().map(HashUtils::calculateHash).collect(Collectors.toList());
    返回 this.transactionHashCache.anyHashExists(hashes) ？ ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
    }
    ```

1. 当处理新收获的块 - 包含 MT' - 时，`TransactionHashesObserver` 尝试在进行状态更改的部分块处理期间将 H(MT') 和 H(X) 添加到 `HashTransactionsCache`。 这失败了，因为 H(X) 已经存在于 `UnconfirmedTransactionsCache` 中，所以收获的块被拒绝 🛑

1. 转到第 5 步，直到 H(MT') 从 `UnconfirmedTransactionsCache` 中过期

![2023 02 27 NEM Stall Post Mortem](/uploads/2023_02_27_NEM_Stall_Post_Mortem_544cb72628.png)

## 使固定

解决方法是更新两个唯一的哈希交易验证器，以检查外部和内部交易哈希。 这可以简单地通过使用 TransactionExtensions.streamDefault() 来完成。

### BatchUniqueHashTransactionValidator

添加“TransactionExtensions.streamDefault”将阻止 MT（或类似的）添加到“UnconfirmedTransactionsCache”。

```java
public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
     如果（groupedTransactions.isEmpty（））{
         返回 ValidationResult.SUCCESS；
     }

     最终 List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
             .flatMap(事务 -> TransactionExtensions.streamDefault(事务)).map(HashUtils::calculateHash)
             .collect(Collectors.toList());
     返回 this.validate(hashes);
}
```

### BlockUniqueHashTransactionValidator

添加“TransactionExtensions.streamDefault”将阻止 MT（或类似的）被添加到新收获的区块中。

```java
公共 ValidationResult 验证（最终块块）{
     如果 (block.getTransactions().isEmpty()) {
         返回 ValidationResult.SUCCESS；
     }

     最终 List<Hash> hashes = block.getTransactions().stream().flatMap(transaction -> TransactionExtensions.streamDefault(transaction))
             .map(HashUtils::calculateHash).collect(收集ors.toList());
     返回 this.transactionHashCache.anyHashExists(hashes) ？ ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
}
```

在区块 4129631 生成后，NEM 网络上的区块生成速度变得缓慢。

2023 年 2 月 27 日 NEM 摊位事后分析

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 觀察

在區塊 4129631 生成後，NEM 網絡上的區塊生成速度變得緩慢。 這種情況是由進入未確認交易緩存的意外交易引起的。 當這筆交易到期時，區塊生產恢複正常。

我們已經確定了意外交易的構成以及它是如何進入未確認交易緩存的。

配置了 1-of-2 多重簽名的多重簽名帳戶發送了兩個相互衝突的交易。 假設兩個共同簽名者名為 A 和 B，多重簽名賬戶名為 M。

## 根本原因分析

發生了以下事件序列：

1. M 發送一個多重簽名交易 MT，其中包含一個內部交易 - X - 由 A 簽名

1. 多重簽名交易提交到鏈上，TransactionHashesObserver（作為 BlockTransactionFactory 的一部分運行）將 H(MT)、H(X) 添加到 HashTransactionsCache

    ```java
    public void notify(final TransactionHashesNotification notification, final BlockNotificationContext context) {
    如果 (NotificationTrigger.Execute == context.getTrigger()) {
    this.transactionHashCache.putAll(notification.getPairs());
    }
    ...
    ```

    重要的是，當創建 TransactionsHashesNotification 時，會使用 streamDefault，它會擴展到外部和內部交易：

    ```java
    protected void notifyTransactionHashes() {
    final List<HashMetaDataPair> 對 = BlockExtensions.streamDefault(this.block)
    .map(t -> new HashMetaDataPair(HashUtils.calculateHash(t), new HashMetaData(this.block.getHeight(), t.getTimeStamp())))
    .collect(Collectors.toList());
    this.observer.notify(new TransactionHashesNotification(pairs));
    }
   
    ```

1. M 發送一個多重簽名交易 MT'，其中包含由 B 簽名的 **SAME** 內部交易 X

1. `BatchUniqueHashTransactionValidator` 檢查 H(MT') 不在 HashTransactionsCache 中，因此它被添加到 UnconfirmedTransactionsCache ✅

    ```java
    public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
            ...
    最終 List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
    .map(HashUtils::calculateHash).collect(Collectors.toList());
   
    返回 this.validate(hashes);
    }
   
    ```

    重要的是，`pair.getTransactions()` 返回僅包含外部交易的 `Collection<Transaction>`。 結果，檢查了 H(MT') != H(MT) 但未檢查 H(X)。

1. MT' 被收割機選為一個區塊。 `BlockUniqueHashTransactionValidator` 和`BatchUniqueHashTransactionValidator` 的邏輯是一樣的，所以隻檢查外層 MT 的 hash。 結果，交易被包含在收獲的區塊中 ✅

    ```java
    公共 ValidationResult 驗證（最終塊
            ...
    final List<Hash> hashes = block.getTransactions().stream().map(HashUtils::calculateHash).collect(Collectors.toList());
    返回 this.transactionHashCache.anyHashExists(hashes) ？ ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
    }
    ```

1. 當處理新收獲的塊 - 包含 MT' - 時，`TransactionHashesObserver` 嚐試在進行狀態更改的部分塊處理期間將 H(MT') 和 H(X) 添加到 `HashTransactionsCache`。 這失敗了，因為 H(X) 已經存在於 `UnconfirmedTransactionsCache` 中，所以收獲的塊被拒絕 🛑

1. 轉到第 5 步，直到 H(MT') 從 `UnconfirmedTransactionsCache` 中過期

![2023 02 27 NEM Stall Post Mortem](/uploads/2023_02_27_NEM_Stall_Post_Mortem_544cb72628.png)

## 使固定

解決方法是更新兩個唯一的哈希交易驗證器，以檢查外部和內部交易哈希。 這可以簡單地通過使用 TransactionExtensions.streamDefault() 來完成。

### BatchUniqueHashTransactionValidator

添加“TransactionExtensions.streamDefault”將阻止 MT（或類似的）添加到“UnconfirmedTransactionsCache”。

```java
public ValidationResult validate(final List<TransactionsContextPair> groupedTransactions) {
     如果（groupedTransactions.isEmpty（））{
         返回 ValidationResult.SUCCESS；
     }

     最終 List<Hash> hashes = groupedTransactions.stream().flatMap(pair -> pair.getTransactions().stream())
             .flatMap(事務 -> TransactionExtensions.streamDefault(事務)).map(HashUtils::calculateHash)
             .collect(Collectors.toList());
     返回 this.validate(hashes);
}
```

### BlockUniqueHashTransactionValidator

添加“TransactionExtensions.streamDefault”將阻止 MT（或類似的）被添加到新收獲的區塊中。

```java
公共 ValidationResult 驗證（最終塊塊）{
     如果 (block.getTransactions().isEmpty()) {
         返回 ValidationResult.SUCCESS；
     }

     最終 List<Hash> hashes = block.getTransactions().stream().flatMap(transaction -> TransactionExtensions.streamDefault(transaction))
             .map(HashUtils::calculateHash).collect(收集ors.toList());
     返回 this.transactionHashCache.anyHashExists(hashes) ？ ValidationResult.NEUTRAL : ValidationResult.SUCCESS;
}
```

在區塊 4129631 生成後，NEM 網絡上的區塊生成速度變得緩慢。

2023 年 2 月 27 日 NEM 攤位事後分析

February-27, 2023 NEM Stall Post Mortem

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## The Discovery
On October 13th, [Toshi](https://twitter.com/toshiya_ma) reported some unexpected behavior to us on [Discord](https://discord.gg/jtZn2mQvsh) in the `#sdk-js` channel. He had been comparing the outputs of the deprecated [TypeScript SDK](https://github.com/symbol/symbol-sdk-typescript-javascript) to the newer [JavaScript SDK](https://github.com/symbol/symbol/tree/dev/sdk/javascript) and noticed that the aggregate transaction hashes were being calculated differently. That…was not expected behavior. Even more concerning was the fact that they were both being accepted (and confirmed) by the network.

## Root Cause
The team quickly identified two critical bugs - one in Catapult (the Symbol client), and one in the TypeScript and Java SDKs.

### Client
In Catapult’s “Fushicho 2” (November 8th 2019) release, a new validator was added to the Aggregate Transaction plugin for the purposes of validating the TransactionsHash field of completed and bonded aggregate transactions. Unfortunately, due to an oversight, it was never registered in the Aggregate Transaction plugin, and thus never called.

```
manager.addStatelessValidatorHook([config](auto& builder) {
        // the following line should have been present but was not
    builder.add(validators::CreateAggregateTransactionsHashValidator()); 

    builder.add(validators::CreateBasicAggregateCosignaturesValidator(
			config.MaxTransactionsPerAggregate,
			config.MaxCosignaturesPerAggregate));
	if (config.EnableStrictCosignatureCheck)
		builder.add(validators::CreateStrictAggregateCosignaturesValidator());
});
```

Due to the rush to launch, we forgot to add a E2E test that would trigger the `Failure_Aggregate_Transactions_Hash_Mismatch` failure code. Consequently, Symbol was launched without proper validation of aggregate transactions hashes.

On top of that, there was a discrepancy in the hash calculation for aggregate transactions between the deprecated TypeScript SDK; the Java SDK; and our Python and JavaScript SDKs.

While the Python and JavaScript SDKs were calculating aggregate transaction hashes correctly, the TypeScript SDK and Java SDK - which we had deprecated earlier this year - were not.

### SDK
The (deprecated) TypeScript SDK has two bugs in its calculation.

Recall that an aggregate transaction is a container of embedded transactions. Each embedded transaction is guaranteed to start on an 8-byte bounday. Zeroed pad bytes are inserted between transactions, whenever necessary, in order to achieve this. When calculating the embedded transaction hash, only the meaningful data of the transaction should be hashed and the zero pad bytes should be excluded. Unfortunately, the TypeScript SDK was including these zero pad bytes in the hash calculation. While frustrating, this does not reduce security.

The real bug was found in the Merkle hash calculation. Due to a improper usage of splice, splice **inserted** instead of **replaced** an element. The second parameter should have been 1 to replace.

```
hashes.splice(i / 2, 0, this.hash([hashes[i], hashes[i + 1]]));
```

Due to both poor test coverage as well as not utilizing our standard test vectors, both of these oversights went unnoticed.

The (deprecated) Java SDK had the same Merkle hash calculation bug as the TypeScript SDK. Surprisingly, it calculated the embedded transaction hashes correctly (without padding).

It is somewhat amusing that these two SDKs have been calculating different aggregate transactions hashes for years and no one noticed until now. At a minimum, they should have been using common test vectors.

### How an Attack Could Work
Due to the missing check of the aggregate transactions hashes, cosignatories are only signing the Aggregate Transaction header. So, the only constraint is that the total embedded transactions size must match the payload_size in the header.

Due to the bug in the invalid Merkle Hash algorithm used by the TypeScript and Java SDKs, the corrupt Merkle Hash only protects a subset of transactions from modification. For example, when there are three transactions, only the first two transactions are protected from modification but not the third. As long as the size of the third transaction does not change, it can be replaced with anything.

### Example Attack: Aggregate Complete
Assume there are three participants Alice, Bob and Charlie that want to swap mosaics.

Alice wants to pay Bob and Charlie each 10 Alpha mosaics.
In exchange, Charlie has agreed to pay 100 XYM.

Alice creates an aggregate complete transaction with three parts:

1. Alice sends 10 Alpaca to Bob
2. Alice sends 10 Alpaca to Charlie
3. Charlie sends 100 XYM to Alice

After creating the transaction, Alice signs it. She passes it to Bob who cosigns it. Bob passes it to Charlie who wants to cheat Alice.

Charlie knows this and replaces the third transaction so that he sends Alice 0 XYM instead. Or, even worse, he could change it so Alice sends HIM 100 XYM!

After replacing the third transaction, Charlie cosigns it and sends it to the network. He and Bob each receive 10 Alpaca from Alice. Alice receives nothing and could end up even sending XYM to Charlie.

### Example Attack: Aggregate Bonded
The previous attack can also be carried out against aggregate bonded transactions.

After creating the transaction, Alice sends it to the network where it is added to the partial transactions cache. Bob submits his cosignature to the network.

At this point, Charlie downloads the transaction. He modifies the third transaction as in the previous section. Next, he downloads Bob’s cosignature from the network and attaches it. Finally, he cosigns it himself, and sends the, now completed, aggregate to the network.

## Assessment
Upon discovery, we had two priorities: get the network patched before a blackhat could take advantage of the bug, and assess the damage on the current chain.

At the time of analysis (October 25th), there were 38,8607 aggregates confirmed on the network.

**Group 1**
- 73,615 (19.07%) were using unpadded hashes along with the correct Merkle hash algorithm.
- 129,987 (33.68%) were using padded transactions hashes, along with the correct Merkle hash algorithm. These are highly likely to have been initiated with the TypeScript SDK. Due to the specifics of the bug in the Merkle hash algorithm, aggregates containing two or fewer aggregates will calculate a cryptographically verifiable hash.

**Group 2**
- 184,471 (47.80%) are using padded transaction hashes along with an invalid Merkle hash algorithm. These are highly likely to have been initiated with the TypeScript SDK. Within those:
  - 102,591 are key linking transactions (therefore issued by single owning account);
- 514 (0.13%) are using unpadded transaction hashes along with the invalid Merkle hash algorithm. These are highly likely to have been initiated with the Java SDK;
- 20 (0.005%) are corrupt and not calculated by one of the above methods. Upon further analysis, these all seem to have been initiated by the miscellaneous scripts. Reviewing these scripts, some of them modify one or more embedded transactions after calculating the aggregate transactions hash but do not recalculate it.

All of the embedded transactions in Group 1 can be crypographically verified as intended in the design of Symbol. None of the embedded transactions in Group 2 can be cryptographically verified. Luckily, once they are finalized, an attacker will be unable to spoof them because the state hashes must match.

## The Fix
### Catapult
In v1.0.3.4, the `AggregateTransactionsHashValidator` is correctly registered in the Aggregate Transaction plugin.

At the fork block of 1’690’500, all aggregate transaction hashes will be calculated from the embedded transaction hashes without padding, and with the correct Merkle hash algorithm.

Prior to the fork block, it will allow aggregate transactions with transactions hashes meeting any of the following criteria:

* Unpadded transaction hashes with correct Merkle Hash algorithms
* Padded transaction hashes with correct Merkle Hash algorithms (TS SDK, <= 2 embedded transactions)
* Unpadded transaction hashes with invalid Merkle Hash algorithms (Java SDK, > 2 embedded transactions)
* Padded transaction hashes with invalid Merkle Hash algorithms (TS SDK, > 2 embedded transactions)
* Hash has matching entry in new corrupt_aggregate_transaction_hashes network configuration setting (20 miscellaneous)

For performance reasons, at and after the fork block, only aggregate transactions with version 2 will be allowed. This version bump will allow the aggregate transactions hash validator to be stateless and run in parallel outside the main commit lock.

### SDKs
The Python and JavaScript SDKs have been updated to support V2 aggregate transactions (complete and bonded).

The TypeScript SDK has been updated to use the correct Merkle hash algorithm, calculate embedded transaction hashes without padding, enable creation of V2 aggregate transactions, and have limited support for reading and verifying V1 aggregate transactions.

The Java SDK has been updated to use the correct Merkle hash algorithm, and have limited support for V2 aggregate transactions.

## Moving Forward
One of the challenges in being a client developer is how you handle vulnerabilities in the network. It’s a constant tradeoff between responsible disclosure and decentralization: speak publicly, and you may find yourself entering into a game of cat-and-mouse with an opportunistic hacker; speak privately, and you isolate a large portion of your userbase. Your attack surface increases with each user you inform, so you’re constantly balancing the tradeoffs.

There is no standard framework to follow - each situation is unique. You’re making battle plans on-the-fly.

It’s clear we need a better way of quickly updating the network.

Traditionally, projects will have “war rooms” where validators and service providers gather - very rarely will exchanges intermingle with developers and other operators, thus increasing the burden of information distribution. We should have a war room established for in the future to quickly disseminate informaton, and as a community hold each other accountable under a gentlemen’s agreement to not leak or distribute information outside of the channel.

It’s also clear we need a better way of releasing. We moved towards a monorepo structure earlier this year to reduce that burden (thanks, Jenkins), but our turnaround time from fork to announcement was almost eight hours. That is unacceptable.

Finally, we need to slow down. In a rush to release Symbol to meet some arbitrary deadline, end-to-end tests were skipped and so were critical audits. Our test coverage across products is poor. And a final bug in Bootstrap led to a subset of nodes not being able to upgrade - a bug that we’re still triaging as we speak.

We’ll be working on a dedicated node deployment and maintenance tool post-fork to help reduce the burden on node operators and ensure we have seamless upgrades in the future. Our team is working on upping the test coverage of both the desktop and mobile wallets and migrating off the TypeScript SDK to our new dual NEM and Symbol JavaScript SDK, and we’re working on a documentation overhaul to ensure undefined or incorrect behavior in the future can be caught by both observant community developers and passionate community members.

Finally, we are awarding a responsible disclosure bounty to Toshi of roughly ¥370,000 JPY. Thanks to our favorite space lion, the Symbol network is secure once again.

On October 13th, Toshi reported some unexpected behavior to us on Discord in the #sdk-js channel.

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 背景について

10月13日に、 [Toshi](https://twitter.com/toshiya_ma) さんが [Discord](https://discord.gg/jtZn2mQvsh) の `#sdk-js` チャンネルにおいて、とある予期せぬ挙動の報告をしました。彼は非推奨の [TypeScript SDK](https://github.com/symbol/symbol-sdk-typescript-javascript) と新しい [JavaScript SDK](https://github.com/symbol/symbol/tree/dev/sdk/javascript) を比較したところ、トランザクションハッシュの計算が異なっていることに気づきました。これは想定していなかった挙動であり、さらに気になった点は、そのどちらもがネットワークに受け入れられている（そして確認されている）ということでした。

## 根本的な原因

チームはふたつの重大なバグを即座に特定いたしました。 - ひとつはCatapult (the Symbol client)に、もうひとつはTypeScript及びJavaのSDKでした。 

#### Clientについて

Catapultは &#34;*Fushicho 2*&#34; (2019年11月8日) において、アグリゲートコンプリーテッドとアグリゲートボンデッドの`TransactionsHash` フィールドを検証することを目的として、アグリゲートトランザクションプラグインに新しいバリデータの追加がされました。ですが見落としがあったため、アグリゲートトランザクションプラグインに登録されずに、その結果呼び出されることがありませんでした。 

```cpp
manager.addStatelessValidatorHook([config](auto&amp; builder) {
        // the following line should have been present but was not
    builder.add(validators::CreateAggregateTransactionsHashValidator()); 

    builder.add(validators::CreateBasicAggregateCosignaturesValidator(
			config.MaxTransactionsPerAggregate,
			config.MaxCosignaturesPerAggregate));
	if (config.EnableStrictCosignatureCheck)
		builder.add(validators::CreateStrictAggregateCosignaturesValidator());
});
```

ローンチを急いだため、 `Failure_Aggregate_Transactions_Hash_Mismatch` の失敗コードを発動するE2Eテストの追加を失念していました。その結果、Symbolはアグリゲートトランザクションのハッシュの検証を適切に経ないままでローンチを迎えておりました。

さらに、非推奨のTypeScript、Javaの SDK、とPython、JavaScriptのSDKの間で、アグリゲートトランザクションのハッシュ計算に相違がありました。

PythonとJavaScriptのSDKはトランザクションのハッシュを正しく計算していましたが、今年の初めに非推奨といたしましたTypeScriptとJavaのSDKはそうではありませんでした。

#### SDKについて

非推奨のTypeScript SDKには、その計算に2つのバグがありました。

まず、アグリゲートトランザクションはトランザクションを埋め込むコンテナであることを思い出してください。それぞれのトランザクションの埋め込みは8バイトを境にスタートすることが保証されています。これを実現するために、ゼロにされたパッドバイトが、必要なときにいつでもトランザクション間に挿入されます。埋め込みトランザクションのハッシュを計算する際には、トランザクションの意味のあるデータのみをハッシュ化し、ゼロパッドバイトは除外する必要があります。残念ながら、TypeScript SDKはこのゼロパッドバイトをハッシュの計算に含めていたのです。そのことは不本意なことでしたが、これによってセキュリティが低下することはありません。

本当のバグは、Merkleハッシュの計算において発見されました。spliceの不適切な使用により、spliceが要素を**置き換える**のではなく、**挿入**してしまったのです。2番目のパラメータは置換のために `1` であるべきだったのです。

```typescript
hashes.splice(i / 2, 0, this.hash([hashes[i], hashes[i + 1]]));
```

テスト網羅率が低かっただけではなく、私たちの標準的な監査を用いていなかったために、これらの過失はどちらとも発見されていませんでした。

非推奨のJava SDKには、TypeScript SDKと同じMerkleハッシュの計算バグがありましたが、驚いたことに埋め込みトランザクションハッシュは（パディングなしで）正しく計算されていました。

この2つのSDKが何年も前から異なるアグリゲートトランザクションハッシュを計算していたにもかかわらず、今まで誰も気づかなかったというのは少々興味深い話ですが、少なくとも共通の監査を用いる必要がありました。

### 想定される攻撃方法

アグリゲートトランザクションのハッシュのチェックができないため、連帯署名人はアグリゲートトランザクションのヘッダーにのみ署名していました。そこには組み込みトランザクションの合計サイズがヘッダーの`payload_size` と一致しなければならないという制約があるのみでした。

TypeScriptとJavaのSDKで使用されていた無効なMerkle Hashアルゴリズムのバグによって、破損したMerkle Hashはトランザクションのサブセットを書き換えから保護するだけでした。例えば、3つのトランザクションがある場合、最初の2つのトランザクションだけが書き換えから保護され、3つ目は保護されなかったのです。3つ目のトランザクションのサイズが変更されない限り、内容を何にでも書き換えることができたのです。

### 攻撃例：アグリゲートコンプリート

モザイク交換をしようとしているAlice、 Bob、Charlieの3人がいるとします。

AliceはBobとCharlieにそれぞれ10アルパカモザイクを支払いたいと考えています。
それと引き換えに、Charlieは100XYMを支払うことに同意しています。

Aliceは以下のような3つの部分からなるアグリゲートコンプリートトランザクションを作成します。 

1. AliceがBobに10アルパカを送る
2. AliceがCharlie10アルパカを送る
3. CharlieがAliceに100XYM送る

トランザクションを作成した後、Aliceはそれに署名します。彼女はそれをBobに渡し、Bobはそれに連署します。BobはそれをCharlieに渡します。CharlieはAliceを欺こうと思っています。

Charlieはこのバグを知っていて、3つ目のトランザクションを書き換え、代わりにアリスに0XYMを送るようにします。あるいは、もっと悪いことに、Aliceが自分に100XYMを送るように書き換えることもできたのです！

3つ目のトランザクションを書き換えた後、Charlieはそれに署名し、ネットワークに送信します。**Charlie**とBobはそれぞれAliceから10アルパカを受け取ります。Aliceは何も受け取らず、もしくは結果としてXYMをチャーリーに送ってしまっていたかもしれないのです。

### 攻撃例：アグリゲートボンデッド

前述した攻撃例は、アグリゲートボンデッドトランザクションに対しても実行することができました。

トランザクションを作成した後に、Aliceはそれをネットワークに送り、そこで部分取引キャッシュに追加されます。Bobは自分の連帯署名をネットワークに送信します。

この時点で、Charlieがそのトランザクションをダウンロードします。彼は前述した方法と同様に、3つ目のトランザクションを書き換えます。次に、彼はBobの連帯署名をネットワークからダウンロードし、それを添付します。最後に、彼は自分自身で署名し、アグリゲートをネットワークに送信します。

## 評価について

発見後私たちは、悪意ある者がこのバグを利用する前にネットワークにパッチを適用することと、現在のチェーンにおける被害を評価することの2点を優先しました。

分析時点（10月25日）では、ネットワーク上で38,8607のアグリゲートが確認されました。

#### グループ1

 * 73,615 (19.07%)は正しい Merkleハッシュアルゴリズムとともに、パディングされていないハッシュを使用していました。
 * 129,987 (33.68%)は正しいMerkleハッシュアルゴリズムとともに、パディングされたトランザクションハッシュを使用していました。これらはTypeScript SDKで開始された可能性が高いです。Merkleハッシュアルゴリズムのバグの仕様上、2つ以下のアグリゲートを含むアグリゲートは、暗号的に検証可能なハッシュを計算します。

#### グループ2

 * 184,471 (47.80%)は、無効なMerkleハッシュアルゴリズムとともに、パディングされたトランザクションハッシュを使用していました。これらはTypeScript SDKで開始された可能性が高いです。
これらのうち:
   * 102,591はキーリンク取引（単一所有アカウントによる発行)
 * 514 (0.13%)は、無効なMerkleハッシュアルゴリズムとともに、パディングされていないトランザクションハッシュを使用していました。これらはJava SDKで開始された可能性が高いです
 * 20 (0.005%)は破損しており、上記のいずれかの方法でも計算されていませんでした。さらに分析すると、これらはすべて雑多なスクリプトによって開始されたようです。これらのスクリプトを見直すと、それらのいくつかは、アグリゲートトランザクションハッシュを計算した後に、1つまたは複数の組み込みトランザクションの変更をしていましたが、再計算は行っていませんでした。

`Group 1`の組み込みトランザクションは、すべてSymbolの設計で意図されたとおりに暗号的に検証することができます。 `Group 2` の組み込みトランザクションは、どれも暗号的に検証することはできません。幸いなことに、いったんそれらが確定すると、ステートハッシュが一致しなければならないので、攻撃者はそれらを偽造することができなくなります。

## まとめ

### Catapult

v1.0.3.4では、 `AggregateTransactionsHashValidator`がアグリゲートトランザクションプラグインに正しく登録されるようになりました。

フォークブロックの 1&#39;690&#39;500以降では、すべてのアグリゲートトランザクションハッシュはパディングなしで、正しいMerkleハッシュアルゴリズムで、埋め込まれたトランザクションハッシュから計算されます。

フォークブロックに先立つ、以下のいずれかの条件を満たすトランザクションハッシュを持つアグリゲートトランザクションを許可します。:
 * 正しい Merkle Hash アルゴリズムを持つ、パディングされていないトランザクションハッシュ
 * 正しい Merkle Hash アルゴリズムを持つ、 パディングされたトランザクションハッシュ（2つ以下のTS SDK埋め込みトランザクション）
 * 無効なMerkle Hashアルゴリズムを持つ、パディングされていないトランザクションハッシュ（2つ以上のJava SDK埋め込みトランザクション）
 * 無効なMerkle Hashアルゴリズムを持つ、パディングされたトランザクションハッシュ（2つ以上のTS SDK埋め込みトランザクション）
 * ハッシュが新しい`corrupt_aggregate_transaction_hashes` ネットワーク構成に一致する項目を持つトランザクション（20件）

パフォーマンス上の理由から、フォークブロック以降では、バージョン2のアグリゲートトランザクションのみが許可されます。このバージョンアップにより、アグリゲートトランザクションのハッシュバリデータはステートレスになり、メインコミットロックの外側で並列に実行されるようになります。

#### SDK

PythonとJavaScriptのSDKが更新され、V2アグリゲートトランザクション (コンプリートとボンデッド) がサポートされました。

TypeScript SDKがアップデートされ、正しいMerkleハッシュアルゴリズムの使用、パディングなしの埋め込みトランザクションハッシュの計算、V2アグリゲートトランザクションの作成が可能になり、V1アグリゲートトランザクションの読み取りと検証が限定的にサポートされるようになりました。

Java SDKが更新され、正しいMerkleハッシュアルゴリズムが使用され、V2アグリゲートトランザクションが限定的にサポートされるようになりました。

## 前へ向かって

クライアント開発者としての課題のひとつは、ネットワークの脆弱性をどう扱うかです。通知するユーザーが増えれば、その分攻撃にさらされる危険性が増しますので、常に責任ある情報公開と分散化のトレードオフが行われているのです。公にそれを話せば、日和見主義的なハッカーと *イタチごっこ* ゲームを繰り返すとになるでしょうし、非公開で話すと、ユーザーベースの大部分を孤立させることになります。

標準的なフレームワークがあるわけではありません。 *その時々に応じて* 対処プランを立てるわけです。

ですがネットワークの更新を迅速に行うためのより良い方法が必要なことは明らかです。 

従来、プロジェクトにはバリデータやサービスプロバイダーが集まる「war room」がありますが、そこでは開発者や他の事業者と交流することはほとんどなく、情報発信の負担が大きくなっています。今後は情報発信を迅速に行うために「war room」を設置し、コミュニティとして、チャンネル外に情報を漏らさない、流さないという紳士協定を結んで、お互いに責任を持つべきでしょう。

また、より良いリリースの方法が必要なことも明らかです。今年初めにその負担を減らすためmonorepo構造に移行しましたが（Jenkinsに感謝）、フォークから発表までに要した時間は *約8時間* でした。これは受け入れがたいことです。

そして、私たちは適切な開発スピードを保つ必要があります。任意の期限に間に合わせるためにSymbolのリリースを急ぐあまり、E2Eのテストが省略され、重要な監査も省略されました。製品全体のテスト網羅率は低いままです。また、Bootstrapの最後のバグにより、一部のノードがアップグレードできない事態が発生し、この事後分析発表時においても処置にあたっているところです。

私たちはノード運用者の負担を軽減し、将来的にシームレスなアップグレードを実現するために、フォーク後のノード展開とそのメンテナンスのためのツールに取り組む予定です。私たちのチームは、デスクトップウォレットとモバイルウォレットの両方のテスト網羅率を向上させて、TypeScript SDKから新しいデュアルNEMおよびSymbol JavaScript SDKへの移行に取り組んでいます。また、将来的には未定義または不正な挙動を、観察力のあるコミュニティ開発者と熱心なコミュニティメンバーの双方が確実に発見できるように、ドキュメントのオーバーホールに取り組んでいます。 

最後に、 私たちはバグの発見をしてくれた [Toshi](https://twitter.com/toshiya_ma) さんに日本円で約¥370,000の懸賞金を授与することをお伝えします。 親愛なる宇宙ライオンのおかげで、Symbolネットワークに安全が取り戻されました。 

10月13日に、 Toshi さんが Discord の #sdk-js チャンネルにおいて、とある予期せぬ挙動の報告をしました。

2022-10-25 事後分析

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 발견
10월 13일, [Toshi](https://twitter.com/toshiya_ma)가 [Discord](https://discord.gg/jtZn2mQvsh)의 `#sdk-js` 채널에서 예기치 않은 동작을 신고했습니다. 그는 더 이상 사용되지 않는 [TypeScript SDK](https://github.com/symbol/symbol-sdk-typescript-javascript)의 출력과 최신 [JavaScript SDK](https://github.com/symbol/symbol/tree/dev/sdk/javascript)의 출력을 비교하던 중 총 트랜잭션 해시가 다르게 계산되는 것을 발견했습니다. 이는... 예상치 못한 행동이었습니다. 더욱 우려스러운 것은 두 트랜잭션이 모두 네트워크에서 승인(및 확인)되고 있다는 사실입니다.

## 근본 원인
팀은 신속하게 두 가지 중요한 버그를 찾아냈습니다. 하나는 Catapult(Symbol 클라이언트)에서, 다른 하나는 TypeScript 및 Java SDK에서 발견되었습니다.

### 클라이언트
Catapult의 "후시초 2"(2019년 11월 8일) 릴리스에서, 완료 및 본딩된 집계 트랜잭션의 트랜잭션 해시 필드를 검증하기 위해 집계 트랜잭션 플러그인에 새로운 유효성 검사기가 추가되었습니다. 안타깝게도 감독 소홀로 인해 집계 트랜잭션 플러그인에 등록되지 않았으며, 따라서 호출되지 않았습니다.

```
manager.addStatelessValidatorHook([config](auto& builder) {
        // 다음 줄이 있어야 하지만 그렇지 않았습니다.
    builder.add(validators::CreateAggregateTransactionsHashValidator()); 

    builder.add(validators::CreateBasicAggregateCosignaturesValidator(
			config.MaxTransactionsPerAggregate,
			config.MaxCosignaturesPerAggregate)));
	if (config.EnableStrictCosignatureCheck)
		builder.add(validators::CreateStrictAggregateCosignaturesValidator());
});
```

출시를 서두르다 보니 `Failure_Aggregate_Transactions_Hash_Mismatch` 오류 코드를 트리거하는 E2E 테스트를 추가하는 것을 잊어버렸습니다. 결과적으로 심볼은 집계 트랜잭션 해시에 대한 적절한 검증 없이 출시되었습니다.

또한, 더 이상 사용되지 않는 타입스크립트 SDK, 자바 SDK, 파이썬 및 자바스크립트 SDK 간에 집계 트랜잭션의 해시 계산에 불일치가 있었습니다.

Python 및 JavaScript SDK는 집계 트랜잭션 해시를 올바르게 계산하는 반면, 올해 초 더 이상 사용되지 않는 TypeScript SDK와 Java SDK는 그렇지 않았습니다.

### SDK
(더 이상 사용되지 않는) TypeScript SDK에는 계산에 두 가지 버그가 있습니다.

집계 트랜잭션은 임베디드 트랜잭션의 컨테이너라는 점을 기억하세요. 각 임베디드 트랜잭션은 8바이트 바운데이에서 시작하도록 보장됩니다. 이를 위해 필요할 때마다 트랜잭션 사이에 0으로 설정된 패드 바이트가 삽입됩니다. 임베디드 트랜잭션 해시를 계산할 때는 트랜잭션의 의미 있는 데이터만 해시하고 0 패드 바이트는 제외해야 합니다. 안타깝게도 TypeScript SDK는 해시 계산에 이러한 제로 패드 바이트를 포함하고 있었습니다. 실망스럽기는 하지만 보안이 저하되지는 않습니다.

실제 버그는 머클 해시 계산에서 발견되었습니다. 스플라이스를 잘못 사용하여 요소를 **대체**하는 대신 스플라이스를 **삽입**했습니다. 대체하려면 두 번째 매개변수가 1이어야 했습니다.

```
hashes.splice(i / 2, 0, this.hash([hashes[i], hashes[i + 1]]));
```

테스트 커버리지가 부족하고 표준 테스트 벡터를 활용하지 않았기 때문에 이 두 가지 간과 사항은 모두 눈에 띄지 않았습니다.

(더 이상 사용되지 않는) Java SDK에도 TypeScript SDK와 동일한 머클 해시 계산 버그가 있었습니다. 놀랍게도 내장된 트랜잭션 해시는 (패딩 없이) 올바르게 계산되었습니다.

이 두 SDK가 수년 동안 서로 다른 총 트랜잭션 해시를 계산해왔는데도 지금까지 아무도 눈치채지 못했다는 사실이 다소 우습습니다. 최소한 공통된 테스트 벡터를 사용했어야 합니다.

공격의 작동 방식 ###
집계 트랜잭션 해시 확인이 누락되었기 때문에 공동 서명자는 집계 트랜잭션 헤더에만 서명하게 됩니다. 따라서 유일한 제약 조건은 포함된 총 트랜잭션 크기가 헤더의 payload_size와 일치해야 한다는 것입니다.

TypeScript 및 Java SDK에서 사용하는 잘못된 머클 해시 알고리즘의 버그로 인해, 손상된 머클 해시는 트랜잭션의 하위 집합만 수정으로부터 보호합니다. 예를 들어, 3개의 트랜잭션이 있는 경우 처음 두 개의 트랜잭션만 수정으로부터 보호되고 세 번째 트랜잭션은 보호되지 않습니다. 세 번째 트랜잭션의 크기가 변하지 않는 한, 무엇이든 대체할 수 있습니다.

### 공격 예시: 집계 완료
모자이크를 교환하려는 앨리스, 밥, 찰리라는 세 명의 참가자가 있다고 가정해봅시다.

앨리스는 밥과 찰리에게 각각 알파 모자이크 10개를 지불하려고 합니다.
그 대가로 찰리는 100 XYM을 지불하기로 동의했습니다.

앨리스는 세 부분으로 구성된 전체 트랜잭션을 생성합니다:

1. 앨리스가 밥에게 알파카 10개를 보냅니다.
2. 앨리스가 찰리에게 알파카 10개를 보냅니다.
3. 찰리가 앨리스에게 100 XYM을 보냅니다.

트랜잭션을 생성한 후 앨리스는 트랜잭션에 서명합니다. 앨리스는 이를 공동 서명자인 밥에게 전달합니다. 밥은 앨리스를 속이려는 찰리에게 이를 전달합니다.

찰리는 이 사실을 알고 세 번째 트랜잭션을 대체하여 앨리스에게 0 XYM을 대신 보냅니다. 또는 더 나쁜 경우, 앨리스를 속이기 위해 앨리스가

Translated with www.DeepL.com/Translator (free version)

10월 13일, Toshi가 Discord의 #sdk-js 채널에서 예상치 못한 행동을 신고했습니다.

2022년 10월 25일, 사후

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 发现
10 月 13 日，[Toshi](https://twitter.com/toshiya_ma) 在“#sdk-js”频道的 [Discord](https://discord.gg/jtZn2mQvsh) 上向我们报告了一些意外行为。 他一直在比较已弃用的 [TypeScript SDK](https://github.com/symbol/symbol-sdk-typescript-javascript) 与较新的 [JavaScript SDK](https://github.com/symbol/ symbol/tree/dev/sdk/javascript) 并注意到聚合交易哈希的计算方式不同。 那……不是预期的行为。 更令人担忧的是，他们都被网络接受（并确认）了。

## 根本原因
该团队很快发现了两个严重的错误——一个在 Catapult（Symbol 客户端）中，一个在 TypeScript 和 Java SDK 中。

### 客户
在 Catapult 的“Fushicho 2”（2019 年 11 月 8 日）版本中，一个新的验证器被添加到聚合交易插件中，用于验证已完成和绑定的聚合交易的 TransactionsHash 字段。 不幸的是，由于疏忽，它从未在聚合交易插件中注册，因此从未被调用。

```
manager.addStatelessValidatorHook([config](auto& builder) {
         // 以下行本应存在但未存在
     builder.add(验证器::CreateAggregateTransactionsHashValidator());

     builder.add(验证器::CreateBasicAggregateCosignaturesValidator(
配置.MaxTransactionsPerAggregate，
配置.MaxCosignaturesPerAggregate));
如果（config.EnableStrictCosignatureCheck）
builder.add(验证器::CreateStrictAggregateCosignaturesValidator());
});
```

由于匆忙推出，我们忘记添加一个会触发 `Failure_Aggregate_Transactions_Hash_Mismatch` 失败代码的 E2E 测试。 因此，Symbol 是在没有对聚合交易哈希进行适当验证的情况下启动的。

最重要的是，已弃用的 TypeScript SDK 之间聚合交易的哈希计算存在差异； Java 开发工具包； 以及我们的 Python 和 JavaScript SDK。

虽然 Python 和 JavaScript SDK 可以正确计算聚合交易哈希值，但我们今年早些时候弃用的 TypeScript SDK 和 Java SDK 却不能。

### 开发工具包
（已弃用的）TypeScript SDK 在其计算中有两个错误。

回想一下，聚合事务是嵌入式事务的容器。 每个嵌入式事务都保证从 8 字节边界开始。 为了实现这一点，只要有必要，就会在事务之间插入置零填充字节。 在计算嵌入式交易哈希时，只对交易有意义的数据进行哈希处理，并排除零填充字节。 不幸的是，TypeScript SDK 在哈希计算中包含了这些零填充字节。 虽然令人沮丧，但这并不会降低安全性。

真正的 bug 是在 Merkle 哈希计算中发现的。 由于 splice 的不当使用，拼接 **inserted** 而不是 **replaced** 一个元素。 第二个参数本来应该是1来代替。

```
hashes.splice(i / 2, 0, this.hash([hashes[i], hashes[i + 1]]));
```

由于测试覆盖率低以及没有使用我们的标准测试向量，这两个疏忽都没有引起注意。

（已弃用的）Java SDK 具有与 TypeScript SDK 相同的 Merkle 哈希计算错误。 令人惊讶的是，它正确地计算了嵌入的交易哈希值（没有填充）。

有点有趣的是，这两个 SDK 多年来一直在计算不同的聚合交易哈希值，直到现在才有人注意到。 至少，他们应该一直在使用通用测试向量。

### 攻击如何运作
由于缺少对聚合交易哈希的检查，共同签名者仅签署聚合交易标头。 因此，唯一的限制是嵌入式事务的总大小必须与标头中的 payload_size 匹配。

由于 TypeScript 和 Java SDK 使用的无效 Merkle Hash 算法中的错误，损坏的 Merkle Hash 仅保护一部分交易不被修改。 例如，当有三个事务时，只有前两个事务不被修改，而第三个不被修改。 只要第三笔交易的大小不变，可以换成任何东西。

### 示例攻击：聚合完成
假设有三个参与者 Alice、Bob 和 Charlie 想要交换马赛克。

爱丽丝想付给鲍勃和查理每人 10 个阿尔法马赛克。
作为交换，查理同意支付 100 XYM。

爱丽丝创建了一个包含三个部分的聚合完整交易：

1. Alice 送 10 只 Alpaca 给 Bob
2.爱丽丝送10只羊驼给查理
3.查理发送100 XYM给爱丽丝

创建交易后，爱丽丝对其进行签名。 她将其传递给共同签名的 Bob。 Bob 将其传递给想要欺骗 Alice 的 Charlie。

查理知道这一点并替换了第三笔交易，因此他向爱丽丝发送了 0 XYM。 或者，更糟糕的是，他可以改变它，让 Alice 给他发了 100 XYM！

替换第三笔交易后，Charlie 对其进行联合签名并将其发送到网络。 他和鲍勃每人从爱丽丝那里得到 10 只羊驼毛。 爱丽丝什么也没收到，甚至可能最终将 XYM 发送给查理。

### 示例攻击：聚合绑定
之前的攻击也可以针对聚合保税交易进行。

创建交易后，爱丽丝将其发送到网络，并在网络中将其添加到部分交易缓存中。 Bob 将他的共同签名提交给网络。

此时，查理下载交易。 他修改了上一节中的第三个事务。 接下来，他从网络上下载 Bob 的共同签名并将其附加。 最后，他自己共同签名，并将现已完成的聚合发送到网络。

## 评估
发现后，我们有两个优先事项：在黑帽可以利用漏洞之前修补网络，并评估当前链的损坏。

在分析时（10 月 25 日），网络上确认的聚合数为 38,8607。

**第一组**
- 73,615 (19.07%) 正在使用未填充的哈希值以及正确的 Merkle 哈希算法。
- 129,987 (33.68%) 使用填充交易哈希，以及正确的 Merkle 哈希算法。 这些很可能是通过 TypeScript SDK 启动的。 由于 Merkle 哈希算法中漏洞的特殊性，包含两个或更少聚合的聚合将计算出一个密码可验证的哈希。

**第 2 组**
- 184,471 (47.80%) 正在使用填充交易哈希以及无效的 Merkle 哈希算法。 这些很可能是通过 TypeScript SDK 启动的。 其中：
   - 102,591 是关键链接交易（因此由单一拥有账户发布）；
- 514 (0.13%) 正在使用未填充的交易哈希以及无效的 Merkle 哈希算法。 这些很可能是用 Java SDK 启动的；
- 20 (0.005%) 已损坏且未通过上述方法之一计算。 进一步分析，这些似乎都是由杂项脚本发起的。 查看这些脚本，其中一些脚本在计算聚合交易哈希后修改一个或多个嵌入式交易，但不重新计算它。

第 1 组中的所有嵌入式交易都可以按照 Symbol 设计中的预期进行密码验证。 第 2 组中的嵌入式交易均无法通过密码验证。 幸运的是，一旦它们最终确定，攻击者将无法欺骗它们，因为状态哈希必须匹配。

## 修复
### 弹射器
在 v1.0.3.4 中，`AggregateTransactionsHashValidator` 在 Aggregate Transaction 插件中正确注册。

在 1'690'500 的分叉块中，所有聚合交易哈希值都将根据嵌入的交易哈希值计算，无需填充，并使用正确的 Merkle 哈希算法。

在分叉块之前，它将允许具有满足以下任何条件的交易哈希的聚合交易：

* 使用正确的 Merkle Hash 算法未填充的交易哈希
* 使用正确的 Merkle Hash 算法填充交易哈希（TS SDK，<= 2 个嵌入式交易）
* 使用无效 Merkle Hash 算法的未填充交易哈希（Java SDK，> 2 个嵌入式交易）
* 使用无效的 Merkle 哈希算法填充交易哈希（TS SDK，> 2 个嵌入式交易）
* 哈希在新的 corrupt_aggregate_transaction_hashes 网络配置设置中有匹配条目（20 个杂项）

出于性能原因，在分叉区块和之后，只允许使用版本 2 的聚合交易。 此版本提升将允许聚合交易哈希验证器无状态并在主提交锁之外并行运行。

### SDK
Python 和 JavaScript SDK 已更新以支持 V2 聚合交易（完整的和绑定的）。

TypeScript SDK 已更新为使用正确的 Merkle 哈希算法，无需填充即可计算嵌入式交易哈希，支持创建 V2 聚合交易，并对读取和验证 V1 聚合交易提供有限支持。

Java SDK 已更新为使用正确的 Merkle 哈希算法，并且对 V2 聚合交易的支持有限。

## 向前进
成为客户端开发人员的挑战之一是如何处理网络中的漏洞。 这是负责任的披露和权力下放之间不断的权衡：公开发言，你可能会发现自己与投机取巧的黑客进入了一场猫捉老鼠的游戏； 私下说话，您会隔离很大一部分用户群。 你的攻击面随着你通知的每个用户而增加，所以你不断地权衡取舍。

没有可遵循的标准框架——每种情况都是独一无二的。 您正在即时制定战斗计划。

很明显，我们需要一种更好的方法来快速更新网络。

传统上，项目将有“作战室”，验证者和服务提供者聚集——交易所很少会与开发商和其他运营商混在一起，从而增加信息分发的负担。 我们应该建立一个作战室，以便将来快速传播信息，并且作为一个社区在君子协议下互相问责，不泄露或传播信息到渠道之外。

同样清楚的是，我们需要一种更好的发布方式。 今年早些时候，我们转向单一仓库结构以减轻负担（感谢 Jenkins），但我们从分叉到发布的周转时间几乎是八个小时。 这是不可接受的。

最后，我们需要放慢脚步。 急于发布 Symbol 以满足某个任意期限，端到端测试被跳过，关键审计也被跳过。 我们对产品的测试覆盖率很低。 Bootstrap 中的最后一个错误导致部分节点无法升级——我们目前仍在对这个错误进行分类。

我们将在分叉后开发专用的节点部署和维护工具，以帮助减轻节点运营商的负担，并确保我们在未来进行无缝升级。 我们的团队正在努力提高桌面和移动钱包的测试范围，并将 TypeScript SDK 迁移到我们新的双 NEM 和 Symbol JavaScript SDK，并且我们正在进行文档大修以确保未来出现未定义或不正确的行为 细心的社区开发人员和热情的社区成员都可以抓住。

最后，我们向 Toshi 提供了大约 370,000 日元的负责任的披露奖金。 感谢我们最喜欢的太空狮子，Symbol 网络再次安全。

10 月 13 日，Toshi 在 #sdk-js 频道的 Discord 上向我们报告了一些意外行为。

2022 年 10 月 25 日，验尸

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## 發現
10 月 13 日，[Toshi](https://twitter.com/toshiya_ma) 在“#sdk-js”頻道的 [Discord](https://discord.gg/jtZn2mQvsh) 上向我們報告了一些意外行為。 他一直在比較已棄用的 [TypeScript SDK](https://github.com/symbol/symbol-sdk-typescript-javascript) 與較新的 [JavaScript SDK](https://github.com/symbol/ symbol/tree/dev/sdk/javascript) 並注意到聚合交易哈希的計算方式不同。 那……不是預期的行為。 更令人擔憂的是，他們都被網絡接受（並確認）了。

## 根本原因
該團隊很快發現了兩個嚴重的錯誤——一個在 Catapult（Symbol 客戶端）中，一個在 TypeScript 和 Java SDK 中。

### 客戶
在 Catapult 的“Fushicho 2”（2019 年 11 月 8 日）版本中，一個新的驗證器被添加到聚合交易插件中，用於驗證已完成和綁定的聚合交易的 TransactionsHash 字段。 不幸的是，由於疏忽，它從未在聚合交易插件中注冊，因此從未被調用。

```
manager.addStatelessValidatorHook([config](auto& builder) {
         // 以下行本應存在但未存在
     builder.add(驗證器::CreateAggregateTransactionsHashValidator());

     builder.add(驗證器::CreateBasicAggregateCosignaturesValidator(
配置.MaxTransactionsPerAggregate，
配置.MaxCosignaturesPerAggregate));
如果（config.EnableStrictCosignatureCheck）
builder.add(驗證器::CreateStrictAggregateCosignaturesValidator());
});
```

由於匆忙推出，我們忘記添加一個會觸發 `Failure_Aggregate_Transactions_Hash_Mismatch` 失敗代碼的 E2E 測試。 因此，Symbol 是在沒有對聚合交易哈希進行適當驗證的情況下啟動的。

最重要的是，已棄用的 TypeScript SDK 之間聚合交易的哈希計算存在差異； Java 開發工具包； 以及我們的 Python 和 JavaScript SDK。

雖然 Python 和 JavaScript SDK 可以正確計算聚合交易哈希值，但我們今年早些時候棄用的 TypeScript SDK 和 Java SDK 卻不能。

### 開發工具包
（已棄用的）TypeScript SDK 在其計算中有兩個錯誤。

回想一下，聚合事務是嵌入式事務的容器。 每個嵌入式事務都保證從 8 字節邊界開始。 為了實現這一點，隻要有必要，就會在事務之間插入置零填充字節。 在計算嵌入式交易哈希時，隻對交易有意義的數據進行哈希處理，並排除零填充字節。 不幸的是，TypeScript SDK 在哈希計算中包含了這些零填充字節。 雖然令人沮喪，但這並不會降低安全性。

真正的 bug 是在 Merkle 哈希計算中發現的。 由於 splice 的不當使用，拚接 **inserted** 而不是 **replaced** 一個元素。 第二個參數本來應該是1來代替。

```
hashes.splice(i / 2, 0, this.hash([hashes[i], hashes[i + 1]]));
```

由於測試覆蓋率低以及沒有使用我們的標準測試向量，這兩個疏忽都沒有引起注意。

（已棄用的）Java SDK 具有與 TypeScript SDK 相同的 Merkle 哈希計算錯誤。 令人驚訝的是，它正確地計算了嵌入的交易哈希值（沒有填充）。

有點有趣的是，這兩個 SDK 多年來一直在計算不同的聚合交易哈希值，直到現在才有人注意到。 至少，他們應該一直在使用通用測試向量。

### 攻擊如何運作
由於缺少對聚合交易哈希的檢查，共同簽名者僅簽署聚合交易標頭。 因此，唯一的限製是嵌入式事務的總大小必須與標頭中的 payload_size 匹配。

由於 TypeScript 和 Java SDK 使用的無效 Merkle Hash 算法中的錯誤，損壞的 Merkle Hash 僅保護一部分交易不被修改。 例如，當有三個事務時，隻有前兩個事務不被修改，而第三個不被修改。 隻要第三筆交易的大小不變，可以換成任何東西。

### 示例攻擊：聚合完成
假設有三個參與者 Alice、Bob 和 Charlie 想要交換馬賽克。

愛麗絲想付給鮑勃和查理每人 10 個阿爾法馬賽克。
作為交換，查理同意支付 100 XYM。

愛麗絲創建了一個包含三個部分的聚合完整交易：

1. Alice 送 10 隻 Alpaca 給 Bob
2.愛麗絲送10隻羊駝給查理
3.查理發送100 XYM給愛麗絲

創建交易後，愛麗絲對其進行簽名。 她將其傳遞給共同簽名的 Bob。 Bob 將其傳遞給想要欺騙 Alice 的 Charlie。

查理知道這一點並替換了第三筆交易，因此他向愛麗絲發送了 0 XYM。 或者，更糟糕的是，他可以改變它，讓 Alice 給他發了 100 XYM！

替換第三筆交易後，Charlie 對其進行聯合簽名並將其發送到網絡。 他和鮑勃每人從愛麗絲那裏得到 10 隻羊駝毛。 愛麗絲什麽也沒收到，甚至可能最終將 XYM 發送給查理。

### 示例攻擊：聚合綁定
之前的攻擊也可以針對聚合保稅交易進行。

創建交易後，愛麗絲將其發送到網絡，並在網絡中將其添加到部分交易緩存中。 Bob 將他的共同簽名提交給網絡。

此時，查理下載交易。 他修改了上一節中的第三個事務。 接下來，他從網絡上下載 Bob 的共同簽名並將其附加。 最後，他自己共同簽名，並將現已完成的聚合發送到網絡。

## 評估
發現後，我們有兩個優先事項：在黑帽可以利用漏洞之前修補網絡，並評估當前鏈的損壞。

在分析時（10 月 25 日），網絡上確認的聚合數為 38,8607。

**第一組**
- 73,615 (19.07%) 正在使用未填充的哈希值以及正確的 Merkle 哈希算法。
- 129,987 (33.68%) 使用填充交易哈希，以及正確的 Merkle 哈希算法。 這些很可能是通過 TypeScript SDK 啟動的。 由於 Merkle 哈希算法中漏洞的特殊性，包含兩個或更少聚合的聚合將計算出一個密碼可驗證的哈希。

**第 2 組**
- 184,471 (47.80%) 正在使用填充交易哈希以及無效的 Merkle 哈希算法。 這些很可能是通過 TypeScript SDK 啟動的。 其中：
   - 102,591 是關鍵鏈接交易（因此由單一擁有賬戶發布）；
- 514 (0.13%) 正在使用未填充的交易哈希以及無效的 Merkle 哈希算法。 這些很可能是用 Java SDK 啟動的；
- 20 (0.005%) 已損壞且未通過上述方法之一計算。 進一步分析，這些似乎都是由雜項腳本發起的。 查看這些腳本，其中一些腳本在計算聚合交易哈希後修改一個或多個嵌入式交易，但不重新計算它。

第 1 組中的所有嵌入式交易都可以按照 Symbol 設計中的預期進行密碼驗證。 第 2 組中的嵌入式交易均無法通過密碼驗證。 幸運的是，一旦它們最終確定，攻擊者將無法欺騙它們，因為狀態哈希必須匹配。

## 修複
### 彈射器
在 v1.0.3.4 中，`AggregateTransactionsHashValidator` 在 Aggregate Transaction 插件中正確注冊。

在 1'690'500 的分叉塊中，所有聚合交易哈希值都將根據嵌入的交易哈希值計算，無需填充，並使用正確的 Merkle 哈希算法。

在分叉塊之前，它將允許具有滿足以下任何條件的交易哈希的聚合交易：

* 使用正確的 Merkle Hash 算法未填充的交易哈希
* 使用正確的 Merkle Hash 算法填充交易哈希（TS SDK，<= 2 個嵌入式交易）
* 使用無效 Merkle Hash 算法的未填充交易哈希（Java SDK，> 2 個嵌入式交易）
* 使用無效的 Merkle 哈希算法填充交易哈希（TS SDK，> 2 個嵌入式交易）
* 哈希在新的 corrupt_aggregate_transaction_hashes 網絡配置設置中有匹配條目（20 個雜項）

出於性能原因，在分叉區塊和之後，隻允許使用版本 2 的聚合交易。 此版本提升將允許聚合交易哈希驗證器無狀態並在主提交鎖之外並行運行。

### SDK
Python 和 JavaScript SDK 已更新以支持 V2 聚合交易（完整的和綁定的）。

TypeScript SDK 已更新為使用正確的 Merkle 哈希算法，無需填充即可計算嵌入式交易哈希，支持創建 V2 聚合交易，並對讀取和驗證 V1 聚合交易提供有限支持。

Java SDK 已更新為使用正確的 Merkle 哈希算法，並且對 V2 聚合交易的支持有限。

## 向前進
成為客戶端開發人員的挑戰之一是如何處理網絡中的漏洞。 這是負責任的披露和權力下放之間不斷的權衡：公開發言，你可能會發現自己與投機取巧的黑客進入了一場貓捉老鼠的遊戲； 私下說話，您會隔離很大一部分用戶群。 你的攻擊麵隨著你通知的每個用戶而增加，所以你不斷地權衡取舍。

沒有可遵循的標準框架——每種情況都是獨一無二的。 您正在即時製定戰鬥計劃。

很明顯，我們需要一種更好的方法來快速更新網絡。

傳統上，項目將有“作戰室”，驗證者和服務提供者聚集——交易所很少會與開發商和其他運營商混在一起，從而增加信息分發的負擔。 我們應該建立一個作戰室，以便將來快速傳播信息，並且作為一個社區在君子協議下互相問責，不泄露或傳播信息到渠道之外。

同樣清楚的是，我們需要一種更好的發布方式。 今年早些時候，我們轉向單一倉庫結構以減輕負擔（感謝 Jenkins），但我們從分叉到發布的周轉時間幾乎是八個小時。 這是不可接受的。

最後，我們需要放慢腳步。 急於發布 Symbol 以滿足某個任意期限，端到端測試被跳過，關鍵審計也被跳過。 我們對產品的測試覆蓋率很低。 Bootstrap 中的最後一個錯誤導致部分節點無法升級——我們目前仍在對這個錯誤進行分類。

我們將在分叉後開發專用的節點部署和維護工具，以幫助減輕節點運營商的負擔，並確保我們在未來進行無縫升級。 我們的團隊正在努力提高桌麵和移動錢包的測試範圍，並將 TypeScript SDK 遷移到我們新的雙 NEM 和 Symbol JavaScript SDK，並且我們正在進行文檔大修以確保未來出現未定義或不正確的行為 細心的社區開發人員和熱情的社區成員都可以抓住。

最後，我們向 Toshi 提供了大約 370,000 日元的負責任的披露獎金。 感謝我們最喜歡的太空獅子，Symbol 網絡再次安全。

10 月 13 日，Toshi 在 #sdk-js 頻道的 Discord 上向我們報告了一些意外行為。

2022 年 10 月 25 日，驗屍

October 25th 2022, Post Mortem

![post-mortem.png](/uploads/post_mortem_7efc587c07.png)

## Background on finalization
Finality is an important concept in blockchain that guarantees that a transaction cannot be changed, cancelled, or revoked. Bitcoin and most chains use probabilistic finalization there. In Symbol, we have both probabilistic and deterministic finalization as separate functions. That is, a transaction is considered final when it is included in a finalized block.

To finalize a block, 2/3 of the active Voting nodes must vote on a hash of the block. Voters are free to participate in that finalization process. Membership changes become effective at the next epoch. Also, at the end of each phase, active voting rights are calculated and that amount is used as the denominator in the next epoch.

## Issue
On Sunday, September 12, we noticed that the network was having problems with the finalization process for epoch 361. This epoch was not unexpected, as we expected this epoch to be a heavy load for the finalization process.

The Voting (voting) node, which registered its voting keys using symbol-bootstrap at network startup, had registered keys for epochs 1 through 360. Many users did not register keys beyond epoch 361 because the importance of updating voting keys regularly was not well known. As a result, many nodes that had voted at epoch 360 did not vote at epoch 361.

Nevertheless, there was still enough consensus to proceed to the next epoch (362). Unfortunately, we stalled here. Several more large nodes stopped voting, and the network was unable to reach agreement on more than a majority of voting nodes.

It appeared to be related to XYM holdings of expired Voting nodes, which is not desirable. Upon investigation, we found that the client properly handled the XYM holdings of accounts that had registered updated voting keys without counting them, but did count the XYM holdings of accounts that had not updated their voting keys. The data stored in the data showed immediately that there was a glitch. If it had been working as designed, the total vote balance should have decreased significantly, but there was little change there.

## Primary Fix
We fixed this bug by excluding accounts with no voting key registered in the current epoch. Also, the supermajority threshold was lowered from 70% to 67%. With these changes, the finalization process will resume as soon as this fix is distributed to supermajority voting accounts.

A hard fork will occur in Block 528,000. This is necessary to correct the calculation of the statistics stored in the Importance Block (since it needs to be verified on all nodes).

Since definitive finalization is implemented as a single function in Symbol, the chain continues to progress while this definitive finalization is in abeyance. Once this finalization is finalized, we expect all blocks to be synchronized quickly.

## Secondary fixes
When a Voting Voting node finishes using its voting key, the node crashes by default. To alleviate this problem, we have changed it so that it is simply logged as an error. This means less noise, however it is not recommended to run nodes in this state for extended periods of time. Nodes that wish to stop voting should be restarted after setting enableVoting to false.

Multisig accounts have always had the inconvenience of requiring another account (the parent account) to pay the fee. This restriction will be relaxed so that in forked blocks, the multisig account can indirectly pay the fee by remitting the fee to the parent account. Note that this does not change the sending behavior of partial transactions that require hash locking.

## Future work
In the current version of Symbol, there is no reward or penalty for Voting voting nodes. While this greatly simplifies the implementation of finalization for launch, it does not create the correct incentive we intended for Voting voting nodes. We plan to add an appropriate system to reward voters in the near future.

We realize that we need to invest in better tools. Being able to monitor the number of active Voting Voting Nodes and the drop in turnout would have alerted us to problems before the final decision process stalled. In the coming months, we will be prioritizing infrastructure, including a new block explorer, an improved REST API, and data analysis that is easy to understand and useful for users and researchers. If you would like to work with us, join us on Discord.

The network has identified a problem with the Epoch 361 finalization process.

News Release