Anyone who has used EOS recently has noticed problems. Transactions not executing. Favorite DApps not working. What was normally more than enough EOS to freely transact without concern has suddenly become far too little. What is going on? What is being done to fix the problem? And is there anything you can do right now to help alleviate the issue?
First, let’s cover the basics of EOS network resources — CPU, NET and RAM.
NOTE: If you would like to skip directly to solutions please scroll to the bottom of this article.
EOS Network Resources
Think of network resources like bodily functions. Each resource plays a crucial role for maintaining and sending information in the EOS “neural” network. Similar to a depleted body, problems occur if resources in an account are too low. Transactions fail. Only after resources have recovered or replenish will normal functioning be restored.
RAM is like memory
Similar to the brain, everything that needs to be saved is stored in RAM. For example, when a smart contract is uploaded on the blockchain, it’s stored in RAM. Without memory you cannot store information. RAM is measured in bytes.
CPU is like energy
Similar to how the body needs energy to make movements, transactions on EOS require CPU. Without CPU you cannot transact information. CPU is measured in microseconds, or the amount of time a Block Producer spends processing a transaction.
NET is like a neural signal
Neural signals for specific bodily movements are always the same. For example, the same neural pathways fire every time you lift your left index finger. Similarly, every action taken on EOS has its own unique “signal”. NET is measured in bytes.
Resource Usage
To access and use CPU/NET you must own and stake EOS tokens. Staking EOS tokens essentially means locking them in your account. The amount of tokens staked to your account reserves network resources pro-rata. If you have 1% of EOS tokens you can access 1% of network resources.
Under normal conditions users can utilize excess or unused CPU/NET, allowing access of resources beyond the amount reserved by a users staked tokens. However, if the network is in congestion mode users cannot access unused CPU. Instead they are limited to the CPU available from their staked tokens, or from leasing.
Network Congestion
EOS blocks are produced every 500 milliseconds. Block Producers must process and validate blocks every 200 milliseconds to account for latency between distributed nodes around the world. This leaves enough time for transactions to be broadcast across the network.
Within each 200 millisecond window a threshold exists at which “rate limiting” begins. The threshold is exceeded at times of very high usage of normally unused network resources.
When rate limiting begins users can no longer access unused network wide CPU. The network is now in “congestion mode”.
Because users can no longer access unused resources they are limited to the amount reserved by the tokens they own. This can cause unexpected “surges” of CPU usage, often times exceeding 100%. Once an account has reached 100% or more usage of CPU/NET you must wait for the resources to naturally replenish as the network recovers, use charitable services offering small amounts of free CPU, delegate CPU/NET from an account that has spare CPU/NET, use Chintai to rent and delegate CPU/NET with an alternative account, or buy more tokens.
Recent Congestion
EOSPlay was hacked in mid-September 2019. The hack was predicated by pushing the network into congestion mode. Following the hack an independent developer known as “Dexeran” began running real time “tests” that are designed to intentionally congest the network every 30 minutes. He has reported his findings and is cooperating with the EOS community to enable solutions.
Dexeran has automated repeat “tests” every 30 minutes. This has caused frustration for users and DApps who were unprepared and normally reliant on excess CPU. When challenged about the ethical implications of the tests in the Chintai telegram channel, Dexeran replied,
“I’m just using the network. Anyone could do the same by simply writing a contract that will consume resources… everyone should have been prepared. Chintai (or any other automated resource delivery service if it exists) could solve the problem. We need to make BPs prepared for acting immediately in case of a REAL problem.”
The ethics of Dexeran’s “tests” are debatable. However, it’s clear that the EOS community needs to transition to solutions that preempt issues caused by network congestion. Until solutions are in place we can expect congestion episodes to continue, either by Dexeran, organic usage, or malicious actors.
Solutions
Block.one published an article proposing that EOS remove the ability to use “free” CPU, grey list accounts and rely on DApps to pay for their users CPU. Removing the ability to access free CPU will push the EOS community to migrate off the expectation of using free CPU and strongly incentivize DApps to pay for their users resources to remain competitive.
Long term DApps will need to obfuscate resource management if we expect them to be used by “grandma”. But it’s debatable whether or not removing access to “free” CPU is the best approach to achieve the intended goal. Regardless, automating blockchain resources is the future whether access to “free” CPU is available or not.
Resource Automation
There are two automation mechanisms for resource management. Chintai and EOSIO 1.8. The EOSIO 1.8 payer is designed for DApps to pay for their users CPU/NET. Chintai Automated Resource Management (ARM) also enables DApps to pay for their user CPU/NET and has these additional features:
- DApps can automate CPU, NET, and RAM for their contract accounts
- Casual users can easily automate their own resources (CPU, NET, RAM)
Chintai automatically buys small amounts of CPU/NET from REX as needed. Users and DApps can also elect to automate purchasing of RAM if needed. No more running out of resources. No more having to manually track resources.
When using ARM, the CHEX token lowers service costs by 75% compared to using EOS. You can acquire CHEX by participating in our auction.
To sign up for Chintai automated resources visit our portal.
If you have comments, questions, or need help, please visit our telegram.
Chintai — Lease Everything
Website | Twitter | Telegram | Medium | LinkedIn | 币乎
EOS 网络拥堵是怎么回事？如何解决？
最近使用过 EOS 的人都注意到了网络拥堵的问题：发起的交易无法执行，常用的 dApp 无法正常运行。
以前账户里的 EOS 足够你任意使用，完全不必担心。不过突然之间，EOS 突然变得太少了，无法支持正常的操作。发生了什么事? 社区在采取什么措施来解决这个问题? 你现在又能做些什么，来缓解这个问题呢?
首先，我们来回顾下 EOS 网络资源的一些基础 — CPU，NET 和 RAM。
备注：如果你想了解解决方案，可以直接跳转到文章结尾部分。
EOS 网络资源
把网络资源想象成人类身体的机能。在EOS的“神经”网络中，每种资源都扮演着维护和发送信息的关键角色。身体可能会精疲力竭，而如果 EOS 账户中的资源过少，也会出现问题，交易会失败。只有在恢复或补充资源之后，才能恢复正常的功能。
RAM 如同记忆一般
和人类大脑相似，需要记忆的信息，会存储在 RAM 之中。例如，智能合约上传到区块链上，会存储在 RAM 之中。如果缺少存储空间，就无法储存信息。RAM 用字节来表示。
CPU 如同能量一样
我们身体需要能量来维持运动，与此相似，EOS 网络上的交易需要 CPU 资源。如果没有 CPU，就无法执行交易。CPU 的单位是毫秒(ms), 表示的是出块节点处理交易所需要的时间。
NET 像神经信号一样
特定身体动作的神经信号总是相同的。例如，每当你抬起左手食指时，同样的神经通路就会激活。
与此相似，在EOS上采取的每个操作都有自己独特的“信号”，传输信号时候会用到 NET 资源。NET 资源的大小，用字节(bytes)来表示。
资源使用量
要使用 CPU/NET 资源，您必须拥有并抵押 EOS 代币。
抵押 EOS 代币，实际上意味着将它们锁定在您的帐户中。在账户中抵押代币，会保留对应比例的网络资源。例如，如果您有 1% 的EOS 代币，您就可以获得 1%的网络资源。
在正常情况下，用户可以利用网络中多余的或未使用的 CPU/NET 资源，从而允许用户使用超出用户代币所对应数量的资源。但是，如果网络处于拥塞模式，用户就只能够使用自己抵押代币或者通过租赁得到的资源，而无法使用网络中未用到的 CPU 资源。
网络拥堵
EOS 的区块每 500 毫秒产生一次。考虑分布在世界各地的节点之间的延迟，出块节点处理和验证区块的时间必须在 200 ms以内。这能够为交易在网络上广播留下足够的时间。
在每200毫秒的窗口中存在一个阈值，如果超过这个阈值，就开始启动 “限速”了。通常未使用的网络资源，如果使用率非常高的时候，就会超过阈值，触发“限速”。
如果开始限速，那么，用户就无法使用网络中空闲的 CPU 资源了，网络就会进入“拥堵模式”。
因为用户不能再使用闲置的资源，他们使用的资源量，只会由抵押的代币数量来决定。这可能会导致意外的CPU使用量“激增”，经常超过100%。
一旦一个帐户的 CPU /NET 使用量达到甚至超过 100%，就无法继续操作了。想要继续使用可以有几种方式，要么需要等待网络资源恢复，或者使用社区提供的免费的福利服务获得少量免费的 CPU，用另外一个账号为该账号抵押 CPU/NET，或者使用 Chintai 租赁 CPU/NET。
最近的 EOS 网络拥堵
2019年9月中旬，EOSPlay 遭到黑客攻击。黑客将网络推入拥塞模式，然后获得预测结果。
在黑客攻击发生之后，一位名为“Dexeran”的独立开发者开始运行实时“测试”，故意每30分钟就阻塞网络。他已经报告了他的发现，并正在与 EOS 社区合作以提出解决方案。
Dexeran每30分钟自动重复“测试”一次。这给用户和 DApp 带来了一些麻烦，他们没有做好准备， 并且通常会用到超额的 CPU。在 Chintai 电报群 里，Dexeran 被人质疑这一测试是否存在道德上的问题，Dexeran 回复称：
“我只不过是在使用 EOS 网络而已。任何人都可以这样做，只要写一个消耗资源的合约就可以了……每个人都应该有所准备。Chintai(或者任何其他存在的自动化资源服务)可以解决这个问题。我们需要让出块节点(BPs)做好准备，以便在出现实际问题时能够立即采取行动。
Dexeran “测试”是否存在道德问题，社区仍然存在争论。然而，很明显，EOS社区需要恰当的解决方案，处理由网络拥塞引起的问题。在解决方案到位之前，我们可以预期，网络拥堵事件将会继续发生，无论是通过 Dexeran，正常使用，或是有人恶意操纵的方式。
解决方案
Block.One 最近发表了一篇文章建议 EOS 取消使用“免费”CPU的方式, 使用灰名单账户作为临时解决方案，并且建议 DApp 为其用户承担 CPU 费用。取消使用免费 CPU 的能力，将促使 EOS 社区不再抱有使用免费 CPU 的期望，并强烈鼓励 DApp 为其用户资源付费，以保持 DApp 的竞争力。
如果我们希望八十岁的老奶奶也能用上 DApp, 那么，长期而言 DApp 需要不再让用户关注资源管理。但是，取消对空闲 CPU 的使用，是否是达成预期目标的最好方式，这点仍然有争议。
但是，不管怎样，无论是否可以让用户使用空闲的 CPU 资源，对区块链资源进行自动化管理，都是未来的趋势。
资源自动化
目前有两种机制，可以实现资源自动化管理： Chintai 和 EOSIO 1.8。
EOSIO 1.8 提供了新的特性，可以让 DApp 为用户支付 CPU/NET 资源开销。Chintai 自动化资源管理服务 (ARM) 也为 DApp 提供了帮助，使得他们可以为用户支付 CPU/NET 资源，并且，还有额外的一些功能：
- DApp 可以为自己的智能合约自动管理 CPU，NET 和 RAM 资源
- 普通用户也可以很轻松的自动管理自己的账号资源(CPU, NET 和 RAM）
Chintai 会根据需要，自动从 REX 租借小额的 CPU/NET 资源，供账户使用。用户和 DApp 也可以根据自己需要，选择让 Chintai 帮自己自动购买 RAM 资源。 通过这种方式，就不用再担心资源不足的问题了，也不再需要手动跟踪资源的使用情况。
使用 Chintai 的自动资源管理服务（ARM）时, 如果用 CHEX 代币支付，相比用 EOS 支付，可以节省 75% 的成本。可以参与 Chintai 正在进行的代币拍卖活动，获取 Chintai 生态代币 CHEX。
如果您有任何问题，欢迎随时联系我们，可以加入Chintai 中文电报群，或者加入中文微信群，与我们联系。
Chintai-Lease Everything
Website | Twitter | Telegram | Medium | LinkedIn | 币乎
이오스 네트워크의 혼잡 그리고 솔루션
EOS를 사용하는 사람들은 이따금 문제를 발견하곤 합니다. 트랜잭션이 실행되지 않는 경우가 있기 때문입니다. 좋아하는 DApp이 작동하지 않습니다. 무슨 일 일까요? 문제를 해결하기 위해 무엇을 해야 할까요?
우리는 먼저 EOS 네트워크 리소스의 기본 (CPU, NET 및 RAM)을 알아야 합니다.
참고: 솔루션으로 바로 건너 뛰려면 이 기사의 맨 아래로 스크롤 하세요.
EOS 네트워크 리소스
네트워크 리소스를 우리의 신체 기능과 같다고 생각하십시오. 각 리소스는 EOS “신경망” 네트워크에서 정보를 유지하고 전송하는 데 중요한 역할을 합니다. 우리 신체와 유사하게 각 부분(계정)의 자원이 너무 적은 경우 문제가 발생합니다. 움직이려 해도 자원이 고갈되어 있는 경우 실패 할 것입니다. 자원이 복구되거나 보충 된 후에만 정상 기능이 복원됩니다.
RAM은 기억(memory)과 같습니다.
두뇌와 마찬가지로 저장해야 할 모든 것은 RAM에 저장됩니다. 예를 들어 스마트 컨트랙트가 블록체인에 업로드되면 RAM에 저장됩니다. 메모리가 없으면 정보를 저장할 수 없습니다. RAM은 바이트 단위로 측정됩니다.
CPU는 에너지와 같습니다.
신체가 움직임을 만들기 위해 에너지를 필요로 하는 방법과 유사하게 EOS의 트랜잭션에는 CPU가 필요합니다. CPU가 없으면 정보를 거래 할 수 없습니다. CPU는 마이크로 초 또는 블록 생산자가 트랜잭션 처리에 소비 한 시간으로 측정됩니다.
NET은 신경 신호와 같습니다.
특정 신체 운동에 대한 신경 신호는 항상 동일합니다. 예를 들어, 왼쪽 집게 손가락을 올릴 때마다 동일한 신경 경로가 작동합니다. 마찬가지로 EOS에 대해 수행되는 모든 작업에는 고유 한 “신호”가 있습니다. NET은 바이트 단위로 측정됩니다.
자원 사용
이오스 네트워크에서 CPU / NET에 액세스하고 사용하려면 EOS 토큰을 소유하고 스테이킹(잠금)해야 합니다. EOS 토큰을 스테이킹 한다는 것은 본질적으로 계정에서 토큰을 잠그는 것을 의미합니다. 귀하의 계정에 스테이킹된 토큰의 양은 사용할수 있는 네트워크 리소스를 의미합니다. EOS 토큰이 1 % 인 경우 1 %의 네트워크 리소스에 액세스 할 수 있습니다.
정상적인 조건에서 사용자는 초과되거나 사용되지 않은 CPU / NET 를 언제든지 활용 할 수 있습니다. 그러나 네트워크가 정체 모드 인 경우 사용자는 가용되지 않은 CPU에 액세스 할 수 없습니다. 대신에, 그들이 사용할 수 있는 CPU는 스테이킹 된 토큰이나 임대를 받은 토큰으로 제한됩니다.
네트워크 혼잡
EOS 블록은 500 밀리 초마다 생성됩니다. 블록 프로듀서는 전세계 분산 노드 간의 대기 시간을 고려하기 위해 200 밀리 초마다 블록을 처리하고 유효성을 검사해야합니다. 이로 인해 트랜잭션이 네트워크를 통해 브로드 캐스트되기에 충분한 시간이 남습니다.
각 200 밀리 초 내에 “속도 제한”이 시작되는 임계 값이 존재합니다. 일반적으로 사용하지 않던 네트워크 리소스가 매우 많이 사용되는 경우 이 임계 값이 초과됩니다.
속도 제한이 시작되면 사용자는 더 이상 사용하지 않는 네트워크 전체 CPU에 액세스 할 수 없습니다. 네트워크가 이제 “혼잡 모드”에 있기 때문입니다.
사용자는 더 이상 리소스에 액세스 할 수 없으므로 본인이 소유한 토큰이 예약 한 양으로 제한됩니다. 이로 인해 예기치 않은 CPU 사용량의 “폭등”이 발생하며 종종 사용자들의 CPU 사용량은 100 %를 초과하게 됩니다. 계정이 CPU / NET 사용률이 100 % 이상에 도달하면 네트워크가 복구 될 때 리소스가 보충 될 때까지 기다려야합니다. 이때는 적은 양의 무료 CPU 를 제공하는 자선 서비스를 사용하거나, 여분의 CPU/NET 가있는 계정에서 CPU / NET 을 위임할 수 있습니다. Chintai를 사용하여 대체 계정으로 CPU / NET을 임대 및 위임하거나 더 많은 토큰을 구입해 보세요.
최근 혼잡
이오스 댑중 EOSPlay는 2019년 9월 중순에 해킹되었습니다. 해킹은 네트워크가 정체 모드에 있을때 행해졌습니다. 이 해킹 이후“Dexeran”이라는 독립 개발자가 30분마다 네트워크를 의도적으로 혼잡하도록 설계한 실시간“테스트”를 시작했습니다. 그는 자신의 연구 결과를보고했으며 EOS 커뮤니티와 협력하여 솔루션을 구현하고 있습니다.
Dexeran은 매 30 분마다 반복 “테스트”를 자동화했습니다. 이로 인해 준비가 되지 않은 일반적으로 잉여 CPU에 의존하던 사용자들은 DApp에 불만을 토로하였습니다. 친타이 텔레그램 채널에서 테스트의 윤리적 영향에 대해 도전 했을 때, Dexeran 은 다음과 같이 대답했다.
“나는 단지 네트워크를 사용하고 있습니다. 자원을 소비하는 컨트랙트를 작성하면 누구나 동일한 작업을 수행 할 수 있습니다. Chintai (또는 다른 자동화 된 자원 전달 서비스가있는 경우) 이러한 문제점을 해결할 수 있습니다. 실제 문제가 발생할 경우 즉시 행동 할 수 있도록 BP 들을 준비시켜야합니다.”
Dexeran의 “테스트”의 윤리는 논란의 여지가 있습니다. 그러나 EOS 커뮤니티는 네트워크 혼잡으로 인한 문제를 미리 대비하는 솔루션으로 전환해야합니다. 해결책이 마련 될 때까지 Dexeran, 유기적 사용 또는 악의적 인 행위자에 의해 혼잡한 네트워크가 언제든지 계속 될 수 있음을 예상 할 수 있습니다.
솔루션
Block.one은 EOS가 “공짜” CPU, 즉 회색 계정을 사용할 수 있는 기능을 제거하고 DApp이 직접 사용자 CPU에 대한 비용을 지불하도록 제안하는 뉴스를 게시했습니다. 공짜 잉여 CPU에 액세스 할 수있는 기능을 제거하면 EOS 커뮤니티는 DApp들이 경쟁력을 유지하기 위해 이러한 비용을 지불하도록 기대 할 것입니다.
장기적으로 DApp 프로젝트들은“할머니”사용자도 그들의 댑을 편하게 사용하게 하기 위해 리소스 관리를 철저히 해야 할 것입니다. 그러나 “공짜” CPU에 대한 액세스를 제거하는 것이 의도한 목표를 달성하는 가장 좋은 방법인지 여부는 논쟁의 여지가 있습니다. 어쨌든 블록체인 리소스 자동화는“공짜”CPU에 대한 액세스가 가능한지 여부에 관계없이 미래입니다.
자원관리 자동화
자원(리소스) 관리를 위한 두 가지 자동화 메커니즘이 있습니다. Chintai와 EOSIO 1.8버젼 입니다. EOSIO 1.8버젼에서 DApp이 사용자 CPU / NET에 대해 지불하도록 설계되었습니다. Chintai ARM (Automated Resource Management)또한 DApp이 사용자 CPU / NET에 대한 비용을 지불 할 수 있으며, 거기에 더해 다음과 같은 추가 기능이 있습니다.
-DApp은 컨트랙트 계정에 대해 CPU, NET 그리고 RAM 까지 자동화 할 수 있습니다.
-일반 사용자 또한 자신의 리소스 (CPU, NET, RAM)를 쉽게 자동화 할 수 있습니다.
Chintai는 필요에 따라 REX에서 소량의 CPU / NET을 자동으로 구매합니다. 사용자와 DApp은 필요한 경우 RAM 구매를 자동화하도록 선택할 수도 있습니다. 자동화를 통해 더 이상 리소스가 부족하지 않게 되며, 더 이상 수동으로 리소스를 추적 할 필요가 없습니다.
ARM을 사용할 때 CHEX 토큰을 사용하면 EOS 로 비용을 지불할 때보다 서비스 비용이 75% 절감됩니다. 토큰판매에 참여하여 CHEX를 구매해 보세요!
Chintai 자동 자원관리에 가입하려면 포털(클릭)을 방문해 보세요.
의견이나 질문이 있거나 도움이 필요하면 텔레그램에 들어오세요.
Chintai-Lease Everything
Website | Twitter | Telegram | Medium | LinkedIn | 币乎
[Spanish Translation]
Network Congestion & Solutions
Cualquiera que haya usado EOS recientemente ha notado problemas. Transacciones que no se ejecutan. Las DApps favoritas no funcionan. Los EOS que normalmente eran más que suficiente para realizar transacciones libres sin preocupaciones, se han convertido repentinamente en demasiado poco. ¿Qué está pasando? ¿Qué se está haciendo para solucionar el problema? ¿Hay algo que pueda hacer ahora mismo para ayudar a aliviar el problema?
Primero, repasemos los conceptos básicos de los recursos de red de EOS: CPU, NET y RAM.
NOTA: Si desea pasar directamente a las soluciones, vaya al final de este artículo.
Recursos de red EOS
Piense en los recursos de la red como funciones del cuerpo. Cada recurso juega un papel crucial para mantener y enviar información en la red “neural” de EOS. Similar a un cuerpo exhausto, los problemas ocurren si los recursos en una cuenta en la blockchain son demasiado bajos. Las transacciones fallan. Sólo después de que los recursos se hayan reparado o repuesto se restablecerá el funcionamiento normal del sistema.
La RAM es como la memoria
Similar al cerebro, todo lo que necesita ser guardado se almacena en la RAM. Por ejemplo, cuando se carga un contrato inteligente en la blockchain, se almacena en la RAM. Sin memoria no puedes almacenar información. La RAM se mide en bytes.
La CPU es como la energía
De manera similar a como el cuerpo necesita energía para hacer movimientos, las transacciones en EOS requieren CPU. Sin CPU no se puede realizar transacciones de información. La CPU se mide en microsegundos, o la cantidad de tiempo que un Productor de Bloques (BPs) pasa procesando una transacción.
NET es como una señal neural
Las señales neuronales para movimientos corporales específicos son siempre las mismas. Por ejemplo, las mismas vías neurales se disparan cada vez que usted levanta el dedo índice izquierdo. Del mismo modo, cada acción emprendida en EOS tiene su propia “señal” única. La NET se mide en bytes.
Uso de los recursos
Para acceder y utilizar CPU/NET debe poseer y colocar en stake tokens de EOS. Hacer stake de los tokens de EOS significa esencialmente bloquearlos en tu cuenta. La cantidad de tokens en stake en tu cuenta, reserva los recursos de la red proporcionalmente. Si tiene el 1% de los tokens de EOS, puede acceder al 1% de los recursos de la red.
En condiciones normales, los usuarios pueden acceder a la CPU/NET excedente o no utilizada, lo que permite el uso de recursos más allá de la cantidad reservada por los tokens de los usuarios. Sin embargo, si la red está en modo congestión, los usuarios no pueden acceder a la CPU no utilizada. En su lugar, se limitan a la CPU disponible basado en los tokens que tengan disponibles en stake o delegados por otros.
Congestión de la red
Los bloques en la blockchain de EOS se producen cada 500 milisegundos. Los productores de bloques deben procesar y validar bloques cada 200 milisegundos para tener en cuenta la latencia entre nodos distribuidos en todo el mundo. Esto deja tiempo suficiente para que las transacciones se transmitan a través de la red.
Dentro de cada ventana de 200 milisegundos existe un umbral en el que comienza la “limitación de velocidad”. El umbral se rebasa en periodos de uso muy elevado de los recursos de red que normalmente no se utilizan.
Cuando comienza la limitación de la velocidad, los usuarios ya no pueden acceder a la CPU de toda la red que no esté en uso. Esto se conoce como “modo de congestión”.
Dado que los usuarios ya no pueden acceder a los recursos no utilizados, se limitan a la cantidad reservada por los tokens que poseen. Esto puede causar “sobrecargas” inesperadas en el uso de su CPU. Una vez que una cuenta ha alcanzado el 100% o más de uso de CPU/NET, debe esperar a que los recursos se repongan naturalmente a medida que la red se recupera, alquilar recursos, utilizar servicios caritativos que ofrecen pequeñas cantidades de CPU gratuita, delegar CPU/NET de una cuenta que tenga CPU/NET de repuesto o comprar más tokens y ponerlos en stake.
Congestión reciente
EOSPlay fue hackeado a mediados de septiembre del presente año 2019. El hacker se basó en llevar la red al modo de congestión. Tras el ataque, un desarrollador independiente conocido como “Dexeran” comenzó a realizar “pruebas” en tiempo real diseñadas para congestionar intencionadamente la red cada 30 minutos. Ha informado de sus hallazgos y está trabajando con la comunidad de EOS para encontrar soluciones.
Dexeran ha automatizado la repetición de “pruebas” cada 30 minutos. Esto ha causado frustración a los usuarios y a las DApps que no estaban preparados y que normalmente dependen del exceso de CPU. Cuando se le cuestionó sobre las implicaciones éticas de las pruebas en el canal de telegram de Chintai, Dexeran respondió,
“Sólo estoy usando la red. Cualquiera podría hacer lo mismo simplemente escribiendo un contrato que consuma recursos… todos deberían haber estado preparados. Chintai (o cualquier otro servicio automatizado de entrega de recursos, si existe) podría resolver el problema. Necesitamos preparar a los BPs para actuar inmediatamente en caso de un problema REAL”.
La ética de las “pruebas” de Dexeran es discutible. Sin embargo, está claro que la comunidad de EOS necesita una transición hacia soluciones que eviten la congestión de la red. Hasta que se encuentren soluciones, podemos esperar que continúen los episodios de congestión, ya sea por parte de Dexeran, el uso orgánico o los actores maliciosos.
Soluciones
Block.one publicó un artículo en el que proponía que EOS eliminará la posibilidad de utilizar CPU “gratuita”, cuentas de lista gris y que dependa de las DApps el pago de el CPU de sus usuarios. La eliminación de la capacidad de acceso a la CPU libre empujará a la comunidad de EOS a migrar de la expectativa de usar CPU libre e incentivará fuertemente a las DApps para que paguen por los recursos de sus usuarios para que sigan siendo competitivos.
Las DApps a largo plazo necesitarán ofuscar la gestión de recursos si esperan que sean utilizadas por la “abuela”. Pero es discutible si quitar o no el acceso a la CPU “libre” es el mejor enfoque para lograr el objetivo deseado. Independientemente de ello, la automatización de los recursos de la cadena de bloqueo es el futuro, independientemente de si el acceso a la CPU “libre” está disponible o no.
Automatización de recursos
Existen dos mecanismos de automatización para la gestión de recursos. Chintai y EOSIO 1.8. El sistema de pago EOSIO 1.8 está diseñado para que las aplicaciones paguen por la CPU/NET de sus usuarios. Chintai Automated Resource Management (ARM) también permite a las DApps pagar por su CPU/NET de usuario y lo siguiente:
- DApps puede automatizar CPU, NET, y RAM para sus cuentas de contrato
- Los usuarios ocasionales pueden automatizar fácilmente sus propios recursos (CPU, NET, RAM)
Chintai compra automáticamente pequeñas cantidades de CPU/NET de REX según sea necesario. Los usuarios y DApps también pueden elegir automatizar la compra de RAM si es necesario. Ya no más, quedarse sin recursos. Ya no más, tener que hacer un seguimiento manual de los recursos.
El token CHEX reduce los costos de servicio en un 75% en comparación con el uso de EOS. Puede adquirir CHEX participando en nuestra subasta.
Para suscribirse a los recursos automatizados de Chintai, visite nuestro portal.
Si tiene comentarios, preguntas o necesita ayuda, por favor visite nuestro telegram.
Chintai-Lease Everything
