[EOS] 이오스(Eos Coin) 코인- EOS.IO DAWN 2.0 공식 출시 및 추후 EOS.IO DAWN 3.0 은?

이오스 코인은 최근 빗썸 거래소에서 상장된 이후로 많은 사람들의 인기를 얻고 있습니다. 빗썸에서 12월에 약 4000원에 상장되어 지금 2배이상의 가격이 올랐습니다. 한때 비트코인이 역대 최고로 상승했을 때, 거의 3만원까지 갔엇는데 최근에 만원 안팎의 가격대를 유지하고 있습니다.

이번에 EOS에서 EOS.IO DAWN 2.0 를 런칭했는데요. 이오스 2.0이라고도합니다. 이것이 무엇인지 간단히 정리해드립니다.

EOS.IO Testnet이 block.one 팀이 유지 관리하는 공개 테스트 네트워크와 공식 출시되었습니다. EOS.IO Testnet는 2017년 가을 로드맵에 계획으로 잡혀져 있었으며, 기존 2017년 12월 21일까지 완료하기로 했었던 알파버전을 이제야 출시한 것입니다.

Testnet의 개발자용 주요 기능은 다음과 같습니다.

- P2P 네트워크 코드

- Wasm Sanitation 및 CPU 샌드박싱

- 리스소 사용량 추적 및 속도 제한

- import 테스트

- 각 블록간 통신

이 테스트는 가동 시간과 액세스를 보장하기 위해 강제적으로 30 TPS로 제한되며, 6개월간 지속적인 디버깅과 함께 업데이트 될 예정이라고 합니다. 이 테스트넷과 함께 Dawn 2.0을 지속적으로 개발할 예정입니다.

1. import 테스트(Genesis Import Testing)

Ethereum 네트워크에서 EOS ERC-20 토큰 배포를 기반으로 초기 상태를 가져올 스냅샷 도구를 구현했습니다. 테스트 네트워크에는 유효한 EOS 공개 키를 등록한 잔액만 포함됩니다. ERC-20 토큰의 약 20 %가 EOS 공개 키에 올바르게 등록되었습니다. 스냅 샷 도구는 Ethereum 계정이 보유하고있는 미등록 ERC-20 토큰에 대한 폴백 도구를 구현하여 서명 된 ethereum 트랜잭션에서 공개 키를 복구 할 수 있습니다. 이것은 모든 EOS ERC-20 토큰의 99 %를 다루지만, Ethereum 개인 키를 EOS.IO 지갑으로 가져와야합니다. 보안을 위해 테스트 네트워크는 대체 프로세스를 통해 복구 된 Ethereum 개인 키를 가져 오도록 사용자에게 직접적으로 요청되지는 않습니다. 테스트하는 동안 EOS 개인 키가 손상된 경우 Ethereum 네트워크에 항상 새 키를 등록 할 수 있습니다.

2. 토큰 푸셋 (Token Faucets)

토큰을 보유하지 않거나 유효한 EOS 공개 키를 아직 등록하지 않은 사람들이 네트워크를 테스트 할 수 있도록 "Faucets" 기능을 구현했습니다.

3. 리스소 사용량 추적 및 속도 제한 (Resource Usage & Rate Limiting)

기본 속도 제한 및 리소스 사용 추적을 구현했습니다. 이것은 대역폭, 데이터베이스 스토리지 및 컴퓨터 사용량을 추적합니다. 현재 속도 제한 알고리즘에는 몇 가지 알려진 버그가 있지만 응용 프로그램 테스트 및 개발을 방해하는 요소는 없습니다. 많은 사람들이 속도 제한이 작동하는 방식, 청구 대상자, 스테이크 토큰을 수입 방식으로 임대 할 수있는 방법에 대해 더 많은 정보를 요구하고 있습니다.

4. 대역폭(Bandwidth)

모든 트랜잭션은 블록 생성자가 구성한 최대 네트워크 대역폭 중 일부를 사용합니다. 트랜잭션에 권한이 필요한 모든 계정의 트랜잭션 크기에 따라 3 일 평균 대역폭이 증가합니다. 대역폭은 응용 프로그램 공급자가 스테이크 토큰을 갖거나 위임 된 토큰을 위임 할 수있는 권한 부여 계정 (계약이 아님)이 필요합니다.

5. 전산 대역폭(Computational Bandwidth)

모든 트랜잭션은 연산을 위해 비용을 소모합니다. 연산은 병렬로 실행될 수 있으므로 각 차선마다 다른 정체가있는 다중 차선 고속도로로 볼 수 있습니다. 각 범위 (차선)에는 독자적인 속도 제한이 있으며 요청 된 동시 범위 (차선) 수에 대해 사용자에게 O (S²)가 청구되고 가장 정체 된 범위를 기준으로 요금이 제한됩니다.

6. 데이터베이스 저장소(Database Storage)

EOS.IO Contract는 응용 프로그램 상태를 저장할 수있는 메모리 내 데이터베이스에 대한 액세스 권한을 가지고 있습니다. 계약서에는 저장되는 총 데이터와 각 독립 데이터베이스 항목에 대한 일정한 오버 헤드 요소를 기준으로 청구됩니다. 이 인 메모리 데이터베이스는 독립적이며 분산 된 대량 호스팅 및 저장을위한 EOS.IO 스토리지 프로토콜과는 별개입니다.

Genesis Import Testing

We have implemented a snapshot tool that will import initial state based upon the EOS ERC-20 token distribution on the Ethereum network. Our test network will only include balances which registered a valid EOS public key. About 20% of ERC-20 tokens have been properly registered to an EOS public key. Our snapshot tool also implements a fallback tool for all unregistered ERC-20 tokens held by an Ethereum account for which we can recover a public key from signed ethereum transactions. This covers 99% of all EOS ERC-20 tokens, but will require importing your Ethereum private key into your EOS.IO wallet.

For security purposes, our test network will not ask users to import their Ethereum private keys recovered via the fallback process. If your EOS private key is compromised while testing, you can always register a new key on the Ethereum network.

Token Faucets

We have also implemented a “faucet” facility to allow testing of the network by those who do not hold tokens or have not yet registered a valid EOS public key.

Resource Usage & Rate Limiting

We have implemented basic rate limiting and resource usage tracking. This tracks bandwidth, database storage, and computational usage. At this time there are some known bugs with our rate limiting algorithm, but nothing that should interfere with testing and developing of applications.

We know that many people have been asking for more information about how rate limiting will operate, who will be billed, and how they can lease their staked tokens for income.

Bandwidth

All transactions consume some of the maximum network bandwidth as configured by the block producers. All accounts whose authority is required for the transaction will have their 3-day average bandwidth incremented based upon the size of the transaction. Bandwidth will require the authorizing account (not the contract) to have staked tokens or to be delegated staked tokens by the application provider.

Computational Bandwidth

All transactions consume some computation. Computation can be executed in parallel, so it can be viewed as a multi-lane highway with each lane having different congestion. Each scope (lane) will have its own independent rate limit and a user will be billed O(S²) for the number of simultaneous scopes (lanes) requested and rate limited based upon the most congested scope.

Database Storage

EOS.IO contracts have access to an in-memory database where they can store application state. The contract is billed based upon the total data they store plus a constant overhead factor for each independent database entry. This in-memory database is independent and separate from the EOS.IO Storage protocol for decentralized bulk hosting and storage.

P2P Network Code

We have a basic implementation of mesh network code that is being demonstrated by our public test network. Block.one is operating 21 independent servers each with one of the initial producers configured.

EOS.IO DAWN 3.0 도 2.0이 공식 완료되면 추후 개발예정인데요. 개발진에서 어떻게 로드맵으로 잡고 있는지 간략히 정리해드리겠습니다. EOS Dawn 3.0은 단일 체인의 수평 스케일링 및 안전한 블록 간 통신을 통한 무한 스케일링을 목표로 하고 있습니다. 이 두 가지 기능을 사용하면 블록 체인 기술을 기반으로 구축 할 수있는 것에 제한이 없으며 블록 체인 네트워크가 분산 된 방식이 될 수 있습니다.

1. 무한한 확장 및 분권화 (Infinite Scaling and Infinite Decentralization)

블록 체인 기술의 holy grail은 두 블록 체인이 다른 블록 체인에있는 모든 것을 검증하지 않고 두 독립 블록 체인 간의 안전한 통신을 가능하게하는 것입니다. 이를 위해서는 하나의 블록 체인을 다른 블록 체인의 라이트 클라이언트로 만들어야합니다. Light 클라이언트는 블록 헤더 및 교정본 만 사용하여 트랜잭션을 인증합니다. 

EOS.IO는 경량 클라이언트 검증을 지원하는 최초의 입증 증거 프로토콜입니다. 이거은 완전성 증명을 생성 할 수있는 유일한 방법이므로 매우 중요한 IO입니다. 즉, 대기중인 챌린지 기간없이 순서대로 다른 체인의 모든 관련 이전 메시지를 수신했음을 증명할 수 있습니다. 전통적으로 라이트 클라이언트는 모든 블록 헤더를 처리해야하지만, EOS.IO는 생산자가 변경되거나 더 최근 블록에서 새 메시지가 필요할 때만 블록 헤더를 처리해야하는 라이트 클라이언트를 활성화합니다. 이것은 빈번한 통신과 함께 사슬 간의 효율적인 의사 소통을 가능하게합니다. 

최악의 경우, 500ms마다 통신하는 두 블록 체인의 오버 헤드는 전송 된 총 메시지 수보다 초당 약 2 건의 트랜잭션만 발생될 수 있습니다. 이 모델에서 생산자의 1/3 이상이 정직한 한 의사 소통이 보장됩니다. 또한 한 명의 제작자라도 손상되면 가벼운 클라이언트 (일명 외부 블록 체인)를 손상시킬 수있는 메시지에 서명하면 자동으로 페널티 처리를 할 수 있습니다. 

마지막으로 다른 블록 체인과 통신하기위한 왕복 시간은 각 체인의 비가역성까지의 대기 시간에 따라 달라집니다. EOS.IO 기반 체인은 외부 EOS.IO 체인에 메시지를 보내고 3 초 이내에 암호로 확인 된 응답을받을 수 있습니다. 이러한 수준의 체인 간 통신 및 보안을 통해 대기 시간이 매우 짧은 체인간에 양방향 페그를 만들 수 있습니다. 양방향 페그가 가장 확실한 예이지만 어떤 B2B 통신도이 같은 방법을 사용하여 수행 할 수 있습니다.

2. 공개적 / 개인적 통신 (Public / Private Communication)

인터 체인 (interchain) 통신을 사용하면 사설 블록 체인이 공용 블록 체인과 안전한 양방향 통신을 수행 할 수 있습니다. 이를 통해 전통적인 블록 체인의 공개 특성에 적합하지 않은 모든 종류의 블록 체인 응용 프로그램을 사용할 수 있습니다. 

3. Development Progress (개발 과정)

공용 테스트 네트워크를 제공하기 위해 코드의 가독성, 성능 및 블록 간 통신의 상당 부분을 리펙토링 할 수 있도록 개발을 두 개의 병렬 경로로 나누었습니다. 이 리팩터링 작업은 eos-noon 지점에서 수행되었습니다. 이전 업데이트에서 우리는 공유 메모리 아키텍처에 중점을두고 개발자가 다른 계약과의 동기식 읽기 액세스 및 원자 트랜잭션을 쉽게 수행 할 수 있도록했습니다. 이 접근 방식의 결과는 단일 하이 엔드 시스템을 넘어서 수평 확장이 손실되었습니다. 

EOS Dawn 3.0을 사용하면 최대 65,000 개의 다른 지역을 사용하여 다중 기계 수평 확장 기능을 복원 할 수 있습니다. 모든 지역은 동일한 계정과 계약 코드를 공유하지만 메모리 데이터베이스는 독립적으로 동작됩니다. 한 지역 내의 계약은 비동기 트랜잭션을 사용하여 다른 지역의 계약자와 통신해야합니다. 이 아키텍처를 사용하면 단일 블록 생성자를 클러스터로 구현할 수 있습니다.

4. (Apple사의 보안 Enclave와의 통합 작업)Working Integration with Apple’s Secure Enclave

마지막 업데이트에서 EOS 개발팀은 Apple, Android 및 많은 스마트 카드에서 사용 된 것과 동일한 타원 곡선을 지원하겠다는 의사를 발표했습니다. EOS의 eos-noon 브랜치에는 최신 MacBook Pro에서 Touch ID (및 Face ID)를 사용하여 메시지를 서하고 검증하는 완벽한 기능 증명 개념이 포함됩니다. 비슷한 코드가 네이티브 iPhone 응용 프로그램에서도 작동합니다. 즉, EOS.IO 기반 모바일 애플리케이션은 알려진 가장 안전한 블록 체인 지갑에 포함될 것입니다. 또한, eos-noon 지점은 이제 여러 서명 유형에 대한 지원을 통합했습니다. 즉, 안전한 장소를 사용하여 eos-noon에서 유효성이 확인 된 거래에 서명 할 수 있음을 의미합니다.

5. 500ms 블록 확인(500 ms Block Confirmation)

eos-noon 지점에서는 500ms 블록 (매초 2 블록)을 지원하기 위해 기본 DPOS 프레임 워크에 여러 가지 변경 사항을 구현했습니다. 이 변경으로 인해 분산 응용 프로그램의 응답성이 크게 향상됩니다. 이것을 달성하기 위해 블록 스케줄링이 어떻게 발생하는지 몇 가지 변경 사항을 도입했습니다. 같은 생산자가 다음 생산자에게 넘겨주기 전에 연속적으로 12 블록을 생산할 것입니다. 이는 생산자 간 생산자 이동 (handoff) 인 블록 생산에서 가장 큰 병목 현상을 해결합니다. 

새로운 구조에서 예기치 않은 대기 시간으로 인해 핸드 오프가 발생할 때마다 몇 개의 블록이 누락 될 수 있지만 핸드 오프 간에는 매우 빠른 확인이 있어야합니다. EOS 개발팀은 다양한 핸드 오프 기간을 실험을 진행할 예정입니다. 핸드 오프 기간이 길수록 정상 동작 중에 손실 된 블록이 줄어들지 만 단일 노드가 다운 될 경우 장애가 길어집니다. 500ms의 시간 간격으로 12 블록마다 손을 내밀 때 "다운 타임"은 단일 제작자가 Steem과 BitShares에서 하나의 블록을 놓치는 것보다 나쁘지 않습니다. 이 경우 첫 번째 확인을 위해 6 초가 걸릴 수 있다고 합니다.

6. Runner Up Producers 제거(Removing Runner Up Producers)

블록 간 통신은 라이트 클라이언트가 활성 생산자 세트가 변경되는 모든 블록을 추적해야합니다. "주자 제작자 목록"은 매분마다 새로 생성자를 추가하거나 제거하여 라이트 클라이언트가 분당 적어도 하나의 블록 헤더를 처리하도록합니다. 생산자 세트 변경 빈도를 줄이기 위해 블록 스케줄링을 변경하여 상위 21 개 생산자 만 포함하도록했습니다.

7. 1초 비가역(One Second Irreversibility)

모든 블록 제작자는 모든 블록에 서명을합니다. 그러면 모든 블록이 제작자가 서명 한 즉시 블록을 되돌릴 수 없게 표시 할 수 있습니다. 제작자(producer)는 블록 높이 당 하나의 블록 헤더에만 서명 할 수 있습니다. 이것은 포크 생산자가 두 포크에서 같은 높이의 블록에 서명 할 수 없다는 것을 의미합니다. 그러한 서명은 생산자 위치의 자동 손실, 잠재적 인 채권 상실 및 잠재적으로 중재에 따른 손해에 대한 책임을 포함하여 여러 가지 방법으로 처리 할 수있는 생산자의 오작동에 대한 암호 증명이됩니다. 다음 블록을 만들기 전에 ⅔+ 시그니처를 수집하는 다른 프로토콜과 달리 EOS DPOS는 서명이 수집되는 동안 블록 체인이 "보류 상태"로 진행할 수 있도록하는 낙관적 인 파이프 라이닝을 수행합니다. 이러한 추가 서명은 블록 체인 외부에서 발생하며 기존의 DPOS Steem이나 BitShares 규칙에 따라 블록이 되돌릴 수 없게 된 후에 정리할 수 있습니다. 이 모델에서는 byzantine 노드의 암호화 증거없이 모든 블록이 2/3 + 서명을 수신 할 수 없으므로 byzantine 내결함성을 얻을 수 있습니다.

8. 프로듀서 셔플링 제거(Removing Producer Schedule Shuffling)

프로듀서 핸드 오프 동안 누락 된 블록의 수를 최소화하기 위해, 연속적인 프로듀서 들간의 대기 시간을 최소화하는 것이 바람직합니다. 뉴욕에있는 생산자가 중국의 생산자를 따라 가기로 예정되어 있다면 정상적인 조건 (블록 간격의 50 %)에서 블록을받는 데 250ms가 걸릴 수 있으며 네트워크 정체가있는 경우 잠재적으로 훨씬 길어질 수 있습니다. 반면 뉴욕과 텍사스의 생산자는 대기 시간이 50ms 밖에되지 않습니다 (블록 간격의 10 %). 즉, 뉴욕에서 텍사스로 이전하는 동안 뉴욕에서 중국으로 이동하는 동안 블록 누락 확률이 훨씬 낮습니다. 

텍사스, 캘리포니아, 하와이, 일본, 중국, 인도, 이스라엘, 이태리, 잉글랜드, 아이슬란드 및 뉴욕으로 블록 생산을 일정하게 계획한다면, 50 ~ 100ms 이상. 그러나 주문이 무작위로 이루어진 경우 평균 속도가 상당히 빨라집니다. 한 프로듀서가 후속 프로듀서를 선택할 가능성을 최소화하기 위해 프로듀서 셔플이 도입되었습니다. 

Infinite Scaling and Infinite Decentralization

The holy grail of blockchain technology is to enable secure communication between two independent blockchains without requiring both blockchains to validate everything on the other blockchain. This requires making one blockchain a light-client of another blockchain.

Light clients authenticate transactions using only the block headers and merkle proofs. EOS.IO will be the first proof-of-stake protocol with support for light client validation. More importantly, it will be the only one capable of generating proof-of-completeness. This means it will be possible to prove you have received all relevant prior messages from another chain in order without having a waiting/challenge period.

Whereas traditionally light clients have to process all block headers, EOS.IO will enable light clients that only have to process block headers when producers change or when a new message is required from a more recent block. This will enable efficient infrequent communication between chains along with frequent communication. In the worst case, the overhead of two blockchains communicating every 500 ms will be about 2 transactions per second above the total number of messages sent.

Under this model, the communication will be secured so long as at least ⅓ of producers are honest. Furthermore, if even one producer is corrupt they can be automatically punished if they sign any message that could potentially corrupt a light client (aka foreign blockchain).

Lastly, the round-trip time for communicating to another blockchain depends upon the latency until irreversibility of each chain. An EOS.IO based chains will be able to send a message to a foreign EOS.IO chain and get a cryptographically verified response in under 3 seconds.

This level of interchain communication and security enables the creation of two-way pegs between chains with very low latency. While the two-way peg is the most obvious example, any business-to-business communication can be performed using this same method.

Public / Private Communication

With interchain communication it will be possible for private blockchains to have secure two-way communication with public blockchains. This enables all kinds of blockchain applications which are not well suited to the public nature of traditional blockchains. For example, someone could create the Swiss-Bank of blockchains that is super secret to everyone but the bank owners and the individuals.

Development Progress

In order to deliver our public test network, we divided our development into two parallel paths so that we could refactor significant portions of our code for readability, performance, and inter-blockchain communication. This refactoring work has been occurring in the eos-noon branch.

In past updates we indicated our intention to focus on shared-memory architectures so that developers could easily perform synchronous read-access and atomic transactions with other contracts. The consequence of this approach was a loss of horizontal scaling beyond a single high end machine.

With EOS Dawn 3.0 we will be restoring the ability to do multi-machine horizontal scaling by use of up to 65,000 different regions. All regions will share the same accounts and contract code, but have independent in memory databases. Contracts within one region must use asynchronous transactions to communicate with their counterparts in other regions. With this architecture a single block producer could be implemented as a cluster.

Working Integration with Apple’s Secure Enclave

In our last update we announced our intention to support the same elliptic curve used by Apple, Android, and many smart cards. Our eos-noon branch now includes a fully functional proof-of-concept where messages are signed and verified using Touch ID (and also Face ID) on the latest MacBook Pro’s. Similar code also works on native iPhone applications. This means that EOS.IO based mobile applications will be among the most secure blockchain wallets known.

Furthermore, the eos-noon branch has now integrated this support for multiple signature types which means it is possible to use secure enclave to sign transactions which will be validated on eos-noon.

500 ms Block Confirmation

On our eos-noon branch we have implemented a number of changes to the underlying DPOS framework to support 500 ms blocks (2 blocks every second). This change will dramatically increase the responsiveness of decentralized applications. To achieve this we have introduced some changes in how block scheduling occurs.

The same producer will now produce 12 blocks in a row before handing off to the next producer. This solves the single biggest bottleneck on block production which is producer-to-producer handoff. Under the new structure unexpected latency may cause a few blocks to be missed every time there is a hand off, but between handoffs there should be very fast confirmation. We will be experimenting with different hand-off periods. The longer the handoff period the fewer missed blocks during normal operation, but the longer the outage will be if a single node goes down. With 500ms and hand off every 12 blocks, the “down time” is no worse than when a single producer misses a single block on Steem and BitShares. In this event it could take 6 seconds for first confirmation.

Removing Runner Up Producers

Inter-blockchain communication requires light clients to keep track of all blocks where the set of active producers changes. The “runner up producer list” causes a new producer to be added or removed every minute which forces light clients to process at least one block header per minute, if not more. In order to reduce the frequency of producer set changes we have changed block scheduling to only include the top 21 producers. We are considering offering some kind of stand-by pay for the runner ups, but they will not actually be tasked with producing blocks.

One Second Irreversibility

Every block producer will sign every block which will enable a block to be marked irreversible as soon as ⅔+ producers have signed it. Producers are only allowed to sign one block header per block height. This means that in the event of a fork producers cannot sign blocks at the same height on both forks. Any such a signature will be cryptographic proof of misbehavior of a producer which can be dealt with by a number of methods including automatic loss of producer position, potential loss of bond, and potentially liability for damages under arbitration.

Unlike other protocols which gather ⅔+ signatures before the next block can be produced, EOS DPOS does optimistic pipelining that allows the blockchain to advance in “pending state” while the signatures are gathered. These additional signatures occur outside the blockchain and can be pruned after a block becomes irreversible under traditional DPOS rules of Steem or BitShares.

Under this model, it is possible to achieve byzantine fault tolerance because it is impossible for any block to receive ⅔+ signatures without cryptographic evidence of the byzantine nodes.

Removing Producer Schedule Shuffling

In order to minimize the number of missed blocks during producer handoff, it is desirable to minimize the latency between consecutive producers. If a producer in New York is scheduled to follow a producer in China it may take 250ms to receive a block under normal conditions (50% of block interval) and potentially much longer if there is network congestion. A producer in New York and Texas on the other hand would only have 50ms of latency (10% of block interval). This means there is a significantly lower probability of missing blocks during a handoff from New York to Texas than from New York to China.

If we schedule block production such that it rotates from New York, to Texas, to California, to Hawaii, to Japan, China, India, Israel, Italy, England, Iceland, and back to New York then there is never a hand off of more than 50 to 100ms. However if the order is randomized then the average hand off will be significantly higher.

Producer shuffling was introduced to minimize the potential of one producer to pick on a subsequent producer. This risk was in a world where producers were presumed to be potentially malicious, but in the world of highly vetted, public, producers with high quality data centers it no longer makes sense. There is a constitution and expected level of behavior along with a process for resolving disputes in the event one producer intentionally harms his neighbor.

Under EOS the producers will vote on the production rotation order in a way that minimizes average latency and minimizes total missed blocks due to Internet network congestion.

EOS Dawn 2.0에는 많은 알려진 문제가 있으며이 초기 릴리스에는 심각한 불안정성이 예상됩니다. 이 릴리즈의 목적은 기본 기능을 입증하는 것이며 개발팀 다음 6 개월 동안 버그를 제거하고 안정성과 성능을 개선 할 예정이라고 합니다. 추가적으로 테스트 네트워크의 안정성을 지원하기 위해 제작자 투표를 비활성화된 상태입니다.

개발자가 아닌분들이 보기에는 너무 복잡한 설명인데 간단하게 정리해드리면,

- 짧은 지연시간

- 블록체인 어플리케이션 호환성 강화

- 수많은 거래를 순차적으로 빠르게 처리가능

- 분산 CPU 기능 성능 업데이트

- 블록체인 안전성 강화

개발팀은 성능이 뛰어나고 분산화 된 애플리케이션 플랫폼이 될 알파 버전 인 EOS Dawn 2.0을 구축한 것에 대해서 자축하고 있으며, 원래 로드맵보다 더 많은 기능을 제공한 것에 대해서는 더 많은 기능을 가지는 이오스 코인이 될 것이라고 봅니다. 개발자들은 이번 업데이트 릴리스로 더 좋은 플랫폼이 될 수 있을 것이라 봅니다. 이더리움에 이어 더 좋은 플랫폼 코인으로 거듭날 수있기를 기대합니다. 이오스 3.0은 2월28일에 릴리스 할예정인데 이것이 호재로 보여질지는 지켜봐야할 것 같네요.