[Chinese & Korean Version Below]

Smart Contract Freeze Update

Chintai has been live for nearly one month. Since launch, Chintai has suffered periods of downtime. In some cases, lenders expecting refunds have been burdened with chronically prolonged wait periods. For those affected, Chintai fully understands why people would be frustrated, disappointed, and skeptical. Understandably, many will need time to repair trust with the Chintai platform.

Our commitment to the EOS community remains squarely aligned with providing a safe and stable token leasing platform. The setbacks we’ve encountered have yielded invaluable learning experiences that will result in a more robust and reliable user experience. Furthermore, discoveries we make while exploring uncharted territory will be leveraged by those who follow in our footsteps.

Incident Review

Chintai is designed to match custom lease orders that are submitted by lenders and borrowers. When an order is matched a series of transactions are initiated. First, interest is paid to the lender and bandwidth is delegated to the borrower. Second, deferred transactions are scheduled which automate the trade lifecycle. System wide issues with deferred transactions have been the primary source of downtime. While we help address the system wide issues with deferred transactions, we’ve implemented solutions that will lead to a more reliable Chintai platform.

Multiple Undelegate Deferred Transactions

The first deferred transaction establishes the point in time that leased bandwidth is undelegated from the borrower. Initiating the undelegation process also starts the 72 hour “unstaking countdown timer” that is built into the EOS core code. After the 72 hour unstaking period, the second deferred transaction (chinrefund) sends borrowed EOS back to the lenders account.

Every time the undelegate bandwidth function is initiated the 72 hour unstaking timer resets. Consequently, the unstaking period never managed to unstake for the full 72 hours, effectively “locking” funds in the contract. This issue resulted in a lack of liquid EOS needed to refund lenders. Furthermore, the liquidity in the Chintai account (from open orders) was being given to people whose orders were finished. The smart contract was frozen on October 15th.

Solution

In response to this issue, Chintai manually observed every action and confirmed that no EOS was lost or accounts had been double credited. There were three groups of users that we needed to address:

1) User had an order that would undelegate at some point in the future.

2) Users who had begun undelegating but the three day countdown timer had not expired.

3) Users that undelegated and should have received their funds back

Users who had been expecting a refund from October 15th to 18th were manually reimbursed. The users who should have unstaked during this period were scheduled to receive their EOS on the 24th.

To circumvent the core EOS code limitation, Chintai implemented an interim solution whereby the undelegate action would be called once every 80 hours (originally 73 hours), effectively guaranteeing liquidity. Chintai is also collaborating with Block.one to redesign the undelegate system contract. After these changes are implemented in the core EOS code, multiple undelegate transactions will be possible without resetting the 72 hour timer.

The ability to call multiple undelegation transactions is necessary for the future of advanced dApps on the EOS mainnet. Without upgrading the undelegate system contract, smart contract based dApps that required multiple undelegate calls within a 72 hour period wouldn’t be unable to function efficiently or properly. Upgrading the undelegate contract will pave the way for many advanced applications in the future.

Next pool according to the table is now scheduled for Tue Nov 06 2018 17:15:50

Undelegate Action & Refunds

When the EOS system-wide contract used to undelegate bandwidth is initiated, it also calls the refund action. The refund action is scheduled to execute at end of the 72 hour unstaking period. This moves the funds from “unstake” to “liquid”. When users were expecting their refund on October 27th, the refund action failed. Actions in smart contracts can fail, even when they have worked many times before. This issue with deferred transactions is system wide and being investigated in great depth.

Without having a subsequent call for the refund action, the liquid EOS remained unstaked without being refunded. One hour passed without the refund action being called and the next batch of orders scheduled to undelegate bandwidth were initiated. Consequently, the 72 hour timer reset for all liquid EOS that was intended to be refunded became locked.

Solution:

Previously, the contract was structured with wrapped deferred transactions. Since deferred transactions are not reliable we are migrating to a different approach. We have implemented a “heart beat” solution whereby actions will be called every 5–10 minutes at the scheduled time of execution. If an action fails, the “heart beat” will continue to call an action until the action is successful.

Funds that were not returned are being returned manually. (As of 10/31/18)

Emergency Multi-Sig & Sponsor Communication

When the refund action failed on October 27th, there was a one hour period which the refund action could have been called manually. In order to manually call an action, Chintai requires signatures from 6 out of 11 sponsor BPs. Chintai was unable to gather the required signatures within one hour, resulting in the 72 hour timer being reset.

Solution

We’ve implemented better monitoring and communication for all sponsor BPs. Sponsor BPs will be able to respond much faster to all issues that require multisig. The time between batches has been extended by 7 hours, which will allow us to make changes to the contract if an action fails. Additionally, we’ve saved a pre-signed multisig contract that will allow us to make changes in emergency situations. The pre-signed multisig contract can only make changes to aspects of Chintai that do not affect overall security.

Mirco-Forks and UI

EOS is designed for enterprise grade throughput. Blocks are made every 500ms and become irreversible every 2–3 minutes. Occasionally, there are micro-forks during the time between a block being found and becoming irreversible. Mirco-forks happen when there is a discrepancy between two or more block producers regarding the validity of a block. Discrepancies may cause nodes to end up on a forked chain. When a fork occurs, nodes will remove the forked blocks and replay over the blocks it missed before continuing on the main chain.

Chintai is designed to be a high performance exchange. This means that the Chintai UI is intended to be a real-time reflection of the Blockchain. Since Chintai is pulling live data from the blockchain in real-time, micro-forks can be reflected in the UI causing inaccurate information to be displayed in areas like the orderbook and in the order/lease history panels.

Currently, other applications on EOS are solving this issue by only following irreversible blocks, resulting in 2–3 minute delays before users see their transactions reflected in the application. DEXEOS is an example of a dApp that uses this approach to manage micro forks. When users submit an order on DEXEOS, orders are displayed as “pending” until the transaction is found in an irreversible block — only then is the order executed.

Solution

We’re exploring several different architectures that will allow us to isolate and disregard micro-forks without corrupting a string of events. Currently there are a number of different approach to take, with following irreversible blocks as just one example. While we don’t have a solution yet, we will continue to develop and update the community with what we learn along the way as we feel this is valuable information that can benefit everybody building on EOS.

Floating Point Truncation Errors

There is a limitation in C++ (EOS coding language) in which the floating point in a smart contract is 64 bits long. In other words, outcomes must be expressed (in binary form) in 64 bits or less (the numerical range). However, when an outcome of a lease is longer than 64 bits the full range of the given outcome gets cut off at 64 (certain divisions and mathematical equations cause a recursive pattern, which results in far more than 64 digits).

Orders that have more than 64 bits can result in lenders not receiving their funds at the end of lease terms. For example, if a lender puts in an order with 10 EOS, but because of lease terms the math works out such that 64bit range is exceeded, then the lender will have 9.999 EOS entitled to their account for refund. Consequently, when the contract initiates the scheduled undelegate action for orginal 10 EOS, there is only 9.999, resulting in a complete failure of the contract.

This error has occurred for a small number of users. In each case we refunded the EOS manually. We’ve implemented a solution to address this issue that should eliminate this anomaly from occurring together.

Thank you, Chintai Community

Those who have used Chintai have played a vital role in helping us pioneer the development of advanced smart contracts and identity systemic flaws in the EOS core code. Chintai will be far more reliable in the near future. Additionally, the table is being set for commercial scale dApps that require complex smart contract design.

Chintai is very grateful for those who have endured the early stage hurdles we’ve faced. Our primary goal is using what we’ve learned to build the premiere interface for token leasing and other core infrastructure needs. We intend to stabilize the current leasing model and build out additional functionality such as a UI for REX, RAM trading, comprehensive airdrop servicing, delegating bandwidth to any account, and much more.

EOS42 — Pioneering a Decentralized Future

WEBSITE

TWITTER

TELEGRAM

MEDIUM

STEEM

EOS42 PROJECTS:

CHINTAI (EOS Token Leasing)

EOS911 (Lost Key and Theft Support)

MEOW (My EOS Wallet)

<한국어 번역- Korean Translation>

스마트 컨트랙트 동결 업데이트

친타이는 한달 전 출시 이후 몇 차례의 점검시간을 가졌습니다. 경우에 따라 임대인들의 이오스 환급이 늦어지는 어려움을 겪었습니다. 친타이는 이분들이 왜 실망하고 회의적이었는지 이해하고 있습니다. 당연히 많은 사람들에게 친타이 플랫폼에 대한 신뢰를 회복할 시간이 필요할 것입니다.

안정적인 토큰임대 플랫폼을 제공하고자 하는 EOS 커뮤니티에 대한 저희의 노력은 계속 될 것입니다. 저희가 이런 어려움은 훌륭한 플랫폼을 제공을 위한 귀중한 경험을 주고 있습니다. 또한 저희가 EOS 라는 새로운 영역을 발전시키기 위해 노력한 부분은 뒤에 따라올 개발자들에 의해 활용될 것입니다.

지난 문제(Incident) 리뷰

친타이는 임대인과 임차인이 제출한 사용자 지정 오더가 매칭되도록 설계되었습니다. 주문이 매칭되었을 때 임대차 계약이 시작됩니다. 우선적으로 임대차를 위한 이오스가 친타이로 이동됩니다. 주문이 매칭되었을시 이자가 임대인에게 지불되고 대역폭이 임차인에게 위임됩니다. 둘째로 거래 사이클이 끝났을 시, 이오스와 대역폭을 반환시키는 지연 거래(예약 거래) 가 발생합니다.

문제1: 여러 개의 Undelegation(대역폭 반환) 예약 거래

첫 번째 예약 거래는 임차인에게서 대역폭을 반환될 때 일어납니다. Undelegation 프로세스를 시작하면 이오스 시스템 코드에 내장된 72시간의 “카운트다운 타이머”가 시작됩니다. 이 72시간 후, 두 번째 예약거래가 발생하며, 이를 이용해 EOS룰 임대인에게 반환시킵니다.

문제2: 또 다른 문제는 이오스 소프트웨어 자체의 deferred transaction (지연 거래, 예약거래) 가 실패하는 경우가 생겨서 발생한 오류입니다.

해결책

이 문제에 대한 해결을 위해 친타이는 모든 작업을 수동으로 바꿔 EOS가 유실되거나 이중입금 등이 되지 않게 확인하였습니다. 저희가 고려해야 할 부분은 다음과 같은 세 가지의 케이스였습니다:

1) 진행중인 임대차 계약을 가지고 있는 사용자

2) 임대차가 만료되었지만 언스테이킹이 시작되지 않은 사용자

3) 언스테이킹이 되어서 이오스를 반환 받아야 하는 사용자

해결책 1: 저희는 이오스 시스템 코드의 한계를 우회하기 위해 80시간 마다 (원래 매 3일에 한번) 한번씩 만료된 임대차에 대한 이오스를 한꺼번에 반환시키기로 결정하였습니다. 이는 임시 솔루션이며 이러한 시스템 문제를 다시 설계하기 위해 블록원 측과 협력하고 있습니다. 이 부분이 해결되면 다시 이오스 반환 스케줄이 일정하게 바뀔 것입니다.

앞으로 이오스 메인넷에 복잡한 dApp들이 올라가기 위해선 이렇게 여러 개의 undelegate 거래를 소화할수 있는 능력이 필요합니다. 이 기능이 없으면 여러 개의 undelegate 을 필요로 하는 dApp들은 제대로 작동하지 못할 것입니다.

해결책 2: 이전에는 스마트 컨트랙트가 지연거래(예약거래) 로 구성되어 있었습니다. 현재 생황에서 지연거래를 신뢰할 수 없으므로 다른 접근 방식을 채택하고 있습니다. 저희는 매 5–10분마다 예정된 거래를 호출시키는 “heart beat” 솔루션을 구현했습니다. 만약 예정된 거래가 실패하면 “하트 비트”는 성공할떄까지 액션을 호출합니다.

아직 반환되지 않은 자금은 수동으로 반환 됩니다. (10/31/18 현재)

BP 다중서명 및 비상회의 문제

10월27일 이오스 반환이 실패하였을 때 저희는 수동으로 환불을 일으킬 수 있는 1시간의 여유가 있었습니다. 수동으로 거래를 일이키기 위해서 친타이는 11명의 BP스폰서중 6명에게 서명을 받아야 합니다. 저희는 1시간 안에 필요한 서명을 모두 받을 수 없어서 이오스 반환이 72시간 연장되었습니다.

해결책

저희는 BP 스폰서들과의 더 빠른 비상 커뮤니케이션/모니터링 시스템을 구축했습니다.

스폰서 BP들은 다중서명이 필요할 시에 더 빨리 대응 할수 있을것입니다. 이오스 반환 스케쥴이 73시간에서 80시간으로 늘어남에 따라 작업이 실패할 경우 이를 수정할수 있는 시간이 늘어났습니다. 또한 비상시 거래를 변경할 수 있는 사전 서명된 다중서명 계약을 저장했습니다. 이 다중서명 계약은 전체 보안에는 영향을 끼치지 않는 범위 내 에서만 사용가능합니다.

Mirco-Forks 및 UI 표시 문제

EOS는 엔터프라이즈 급 처리량을 위해 설계되었습니다. 블록은 500ms마다 만들어지고 2~3 분마다 돌이킬 수 없게 됩니다. 때로는 거래가 되돌릴 수 없게 되기 전에 블록 사이에 마이크로 포크(Micro-forks) 가 생길 수 있습니다. 마이크로 포크는 트랜잭션의 거래의 일부분이 무효화 될 떄 발생합니다.

Chintai는 고성능 거래소로 설계되었습니다. 즉, Chintai UI는 EOS Blockchain을 실시간으로 반영하기 위해 만들어졌습니다. Chintai는 EOS 블록체인에서 실시간 데이터를 가져오고 있기 때문에 마이크로 포크가 UI에 반영될 경우, 부정확 한 정보가 UI에 표시 될 수 있습니다.

현재 EOS의 다른 dApp 들은 거래시 2–3 분의 지연을 통해 되돌릴수 없는 블록이 표시될 떄까지 기다립니다.

해결책

Chintai와 같은 복잡한 시스템은 State Machine 을 통해 백엔드에서 이벤트를 처리합니다. State Machine 은 이벤트를 순서대로 놓습니다 (A, B, C 등). 마이크로 포크로 인해 이벤트가 올바르지 않으면 마이크로 포크 이후의 모든 이벤트가 부정확 할 수 있습니다. 저희는 일련의 이벤트를 손상시키지 않고 마이크로 포크를 격리/무시할 수 있는 여러 가지 아키텍처를 연구 중입니다.

소수점 자르기 오류 및 해결

스마트 컨트랙트의 이동 소수점은 64비트 길이로 제한 (EOS 언어 C++ 사용시) 되어 있습니다. 즉 결과는 64비트 이하 (2진법형식) 로 표현 되어야 합니다. 친타이 플랫폼을 구축할 때 설계상 0.0001 EOS의 차이가 있는 오류가 발견되었습니다. 예를 들어, 임대인이 10 EOS 주문을 했지만 임대 조건에 의해 64비트 범위를 초과하는 계산이 이루어지고, 이 상황에서 임대 취소 시 9.999 EOS 를 환급 받게 되는 경우가 있었습니다.

이 오류는 소수의 사용자에게 발생하고 있습니다. 현재 저희는 이 문제를 해결하기 위한 솔루션을 구축하였으며, 앞으로 이러한 현상이 일어나지 않을 것입니다.

친타이 사용자 여러분 감사합니다.

친타이를 사용하는 유저 분들께서는 EOS 프로토콜 내의 스마트 컨트랙트 발전의 개척을 돕는데 중요한 역할을 하고 계십니다. 친타이는 가까운 시일 내에 더욱 믿을만한 플랫폼으로 만들어 질것입니다. 또한 이를 통해 엔터프라이즈 급 dApp들이 복잡한 스마트컨트랙트 디자인을 하는데 참고 할 수 있을 것입니다.

친타이는 이러한 초기의 어려움을 참아준 분들에게 매우 감사합니다. 저희의 목표는 저희가 배운 것들 것 토대로 더 멋진 토큰임대 인프라를 구축하는 것입니다. 저희는 현재의 임대차 모델을 안정시키고 앞으로 EOS REX의 UI, RAM 거래, 에어드롭 서비스, 다른 계정에 대역폭 위임 등과 같은 추가 기능들을 구축하고자 합니다.

EOS42 — Pioneering a Decentralized Future

【中文/Chinese 翻译】 Chintai 智能合约冻结的更新信息

Chintai上线至今,已经近一个月。自上线以来,Chintai遭遇了几次下线维护。在某些情况中,有些贷方的预定还款时间遭遇了较长的延迟。对于那些受影响的人,Chintai团队完全理解用户们会对此感到沮丧,失望并持着怀疑的态度。我们也理解,很多用户将会需要时间来重新建立起他们对Chintai租赁平台的信任。

我们对EOS社区的承诺仍然是:为持币人们提供一个安全稳定的代币租赁平台。在这期间遇到的挫折给予了我们宝贵的学习经验,我们将会通过吸取这些知识来为大家带来一套更健全和可靠的用户体验。此外,但愿那些追随着我们脚步的EOSIO开发者们,能够利用到我们在探索这些EOSIO的未知领域时所收获的开发经验。

事件回顾

Chintai的设计中,会将用户自行提交的租借订单和出租订单相匹配。当一张订单被匹配时,会发起一系列的交易。

第一步,智能合约会收取租赁者(borrower)的租金转给出租者(lender)支付利息,并将带宽(bandwidth)资源抵押给租赁者(borrower)。

第二步,智能合约将会部署一系列的延期交易(deferred transactions),以使交易周期(trade lifecycle)自动化。在系统中,这些延期交易所造成的问题是Chintai 下线的主要原因。在帮助解决有关延期交易的系统性问题的同时,我们已经实施了一个解决方案,这会使Chintai平台变得更可靠。

赎回代币(undelegate)的多笔延期交易

第一笔延期交易是为了确定租赁者所租的带宽在未来被取消质押的时间点。

在启动解除授权过程的同时,内置于EOS核心代码中的“72小时倒数计时器“也会被启动。在过了72小时的解除抵押(unstaking) 周期后,第二个延期交易(chinrefund功能), 将会把被租的EOS发回到出租者的账户。

但是,每次调用赎回带宽的函数(undelegate bandwidth function)时,系统内置的72小时的解倒数计时器会被重设。这造成了赎回操作无法在72小时过后终结,从而造成了智能合约之中的资金遭遇了“锁定“。这一问题导致了Chintai智能合约缺乏流动的EOS,而无法向出租方返还资金。

此外,Chintai账户(来自未结订单)的流动资金,被转给了订单已完结的用户们那里。因此,智能合约于10月15日被冻结。

【解决方法】

针对这个问题,Chintai手工观察每一笔操作(action),并确认没有EOS丢失或账户被重复记账。我们需要处理的情景,涉及到三类用户:

1)用户的订单会在未来某个时间点赎回
2)用户的订单已经开始赎回,但三天倒计时还没有结束。
3)用户的订单已经赎回,应当收到退还的资金

从10月15日到18日期间,本应收到退款用户的订单,会经过手动退款处理。在此期间订单赎回的用户,原计划是在10月24日收到他们的EOS。

为了规避EOS核心代码的限制,Chintai实现了一个临时解决方案,即每80个小时(最初是73个小时)调用一次取消质押的(undelegate)操作,从而有效地保证了流动性。Chintai也在与Block.one合作,重新设计赎回的系统合约。在核心EOS代码中实现这些更改之后,可以实现多笔赎回操作,而不会遇到72小时倒计时器重置的问题。

调用多笔赎回交易(undelegation transactions)的能力, 对于未来在EOS 主网上开发高级DApp是必要的。如果系统合约中赎回(undelegate)的功能不进行更新,那么,如果智能合约需要在72小时内多次调用赎回(undelegate)功能,就无法有效正确的运行。对undelegate的功能进行改进升级,将会为未来许多高级应用程序铺平道路。

赎回(Undelegrate)操作 & 退款

当EOS系统合约当赎回带宽当功能启动时,也会调用退款的功能。退款操作被设定为在取消质押后的72小时会执行。这会将资金从“赎回中”的状态变为“流动”状态。 用户期待他们的退款应该于10月27日退回,但是退款操作执行失败。在智能合约之中的操作会出现失败,即便之前很多次顺利执行过。这一延时交易的问题是系统范围内的,我们也正在进行深入的研究。

没有后续的调用退款的操作,流动状态的EOS代币处于未抵押的状态,没有退还给用户。一个小时过去了,没有调用退款操作,下一批设定好的赎回抵押的批量操作会被启动。因此,72小时计时器重置,所有原本流动状态用于退还的EOS,会被锁定。

【解决方法】

在此之前,合同的结构是打包延迟交易。由于延迟交易不可靠,我们正在换用另一种方法。我们已经实现了一个“heart beat(心跳)”解决方案,在执行计划的时间内,每5–10分钟就会调用一次操作。如果一个操作失败了,“心跳”方案将继续调用操作,直到成功为止。

到10月31日时仍未退还的资金,我们会手动退还.

紧急状态下的多签 & Chintai赞助者沟通

当10月27日退款操作失败时,有一个小时的时间可以手动调用退款操作。为了手动调用一个操作,Chintai需要11个赞助者中的6个BPs签名。Chintai无法在一小时内收集到所需的签名,导致72小时计时器被重置。

【解决方式】

我们为Chintai项目所有的BP赞助者们,实现了一个更好的监控和沟通方式。BP赞助者将会更快地应对所有需要多签的问题。批次之间的时间已经延长了7个小时(现在每批操作之间会间隔8小时),如果操作失败,我们可以修改智能合约。此外,我们还保存了一个预先签署的multisig合约,允许我们在紧急情况下进行更改。预签的多签智能合约只能对Chintai中不影响整体安全的功能进行修改。

微分叉和UI

EOS是为企业级吞吐量而设计的。区块每隔500毫秒产生,每隔2–3分钟成为不可逆状态。偶尔会在区块创建和变成不可逆区块这个时间段中,出现微分叉。当两个或多个出块节点在验证区块的有效性方面存在差异时,就会产生微分叉。差异可能导致节点最终处于分叉链上。当fork发生时,节点将删除分叉的区块,并在继续跟进主链之前重播(replay)它错过的块。

Chintai被设计为一个高性能的交易所。这意味着Chintai 的UI是EOS区块链的实时反映。由于Chintai正在从EOS区块链中提取实时数据,微叉可以在UI中反映,导致在Chintai界面中例如待成交订单列表(orderbook)和订单/出租订单历史中,所显示的信息不准确。

目前,EOS上的其他应用程序通过只执行不可逆的块来解决这个问题,这种实现方式使得用户需要等待2~3分钟,才会看到自己的交易反映在应用程序之中。DEXEOS就是使用这种方法来处理微分叉情形的一个例子。当用户在DEXEOS上提交订单时,订单将显示为“等待状态(pending)”,直到交易被包含在一个不可逆的区块中之后 — — 才执行订单。

【解决方式】

我们正在探索几种不同的架构方式,使得我们可以在不破坏一系列事件的情况下,隔离和忽略微叉。目前有许多不同的方法可以采用,使用不可逆区块只是一个例子。虽然我们还没有解决方案,但我们将继续开发,并将在此过程中了解到的信息分享给社区,因为我们认为这些有价值的信息,可以帮助所有在EOS上创建产品的人。

浮点数截断错误

在c++ (EOS用到的编程语言)中有一个限制,其中智能合约中的浮点数是64位长。换句话说,结果必须以64位或更少(数值范围)表示(以二进制形式)。然而,当租约的结果超过64位时,给定结果的整个范围将在64位时被截断(某些划分和数学方程式会导致递归模式,结果将远远超过64位)。

超过64位(64 bits)的订单,可能导致出租者在租约到期时无法收到资金。例如,如果一个出租者提交了一个有10个EOS的订单,但是由于租赁合约的关系,计算结果是超过了64位的范围,那么出租者将会有9.999个EOS退还到他们的账户中。因此,当智能合约启动预定的undelegate操作将原先的10个EOS退还时,只有9.999个,导致合约完全失败。

这个错误发生在少数用户身上。在每种情况下,我们都是手动返回EOS。我们已经实现了一个解决方案来解决这个问题,应该可以消除这种异常现象。

感谢Chintai社区

在我们探索高级智能合约的开发和识别EOS核心代码中的系统性缺陷方面, 使用Chintai的用户发挥了重要的帮助作用。Chintai在不久的将来,会更加可靠。此外,这些探索也为商业规模的DApp打下了基础,它们会需要用到复杂的智能合约设计。

Chintai 非常感谢那些与我们一起经历了这些早期问题的用户。我们的主要目标是,使用我们所学到的经验,来构建用于代币租赁和其他核心基础设施需求的首要( premiere)接口。我们打算让目前的租赁模式更加稳定,并建立额外的功能,如为REX创建UI, 支持RAM交易,全面的空投服务,为任何帐户抵押带宽,以及更多更多事情。

EOS42 — 开创去中心化解决方案的未来