안녕하십니까?? 
Dan의 계정에서 5시간 전 EOS의 개발 현황에 대해 포스팅이 되었습니다.
EOS에 대해 관심이 많으신 분들은 참고하시라고 공유드립니다. 특히, 기술적인 용어를 많이 쓰다보니 저같은 문과생들은 이해를 못하는 부분이 많은데요.
한마디로 결론낸 맨 마지막의 Dan의 발언처럼 되었으면 좋겠습니다. ^^
◎ EOS 개발 업데이트
https://steemit.com/eos/@dan/ukoxz-eos-io-development-update
EOSIO BIOS
컴퓨터의 BIOS는 하드웨어에 내장되어 있으며 운영 체제를 시작하기 전에 컴퓨터에 가장 먼저 로드됩니다. 이번 주에는 EOSIO 블록체인 bootstrap 프로세스를 가능한 한 간단하게 만들기 위해 운영 체제 메타포를 계속 사용합니다 (예 : 컴퓨터 BIOS). 블록체인은 이제 매우 간단한 초기 상태로 시작됩니다.
이 초기 계정은 리눅스 시스템의 루트 계정과 같으며,이 권한은 더 높은 수준의 운영 체제 스마트 계약으로 이 권한을 얻을 때까지 무제한으로 사용할 수 있습니다. 이 초기 상태에서 @ eosio.system 계정은 다음을 구현하는 운영 체제 스마트 계약을 업로드합니다.
- 보팅, 네트워크 대역폭, CPU 대역폭, 램 및 스토리지 등
- 생산자 및 대리인 보팅
이 초기 상태를 EOSIO 기반 블록 체인을 임의의 수의 사용 사례 및 거버넌스 구조에 적용 할 수있는 배아 줄기 세포로 볼 수 있습니다. 모든 사례는 단단한 포크 없이도 업데이트 및 조정할 수 있습니다.
핵심 EOSIO 소프트웨어를보다 간단하고 쉽게 테스트 할 수 있으므로 이 접근법을 통해 많은 이점을 얻을 수 있습니다.
블록 제작자의 동적 수
이것의 주요한 결과는 EOSIO 블록체인이 이제 @ eosio.system 스마트 계약에 대한 간단한 업데이트로 변경 될 수있는 동적 블록 생성자를 지원한다는 것 입니다. 이 값은 여전히 21 개의 프로듀서로 설정되지만 더 이상 하드 코딩되지 않습니다.
역동적으로 만드는 주된 이유는 많은 개인 블록 체인의 경우 21 명의 생산자가 과도기를 뛰어 넘기 때문입니다. 민간 블록 체인을 기업에서 사용하는 경우 생산자와 테스트 네트워크가 단 하나의 생산자만 원하는 경우가 있습니다.
측광
역사적으로 우리는 각 거래가 블록 생산자가 주관적으로 측정한 실행 시간이 최대 1ms임을 나타 냈습니다. 실행을 위해 최대 50ms가 걸릴 수있는 트랜잭션에 대한 요구가 있음을 알았고 개발자가 실행에 소요되는 시간이 50us 미만인 트랜잭션을 설계하도록 유도하여 효율성을 장려하고자합니다. 우리의 원래 모델에서 모든 트랜잭션은 50ms 또는 1ms가 1ms 미만으로 최적화 할 인센티브가 없더라도 동일한 CPU를 사용했습니다.
런타임은 주관적이며 동일한 컴퓨터에서 실행되는 다른 활동에 따라 달라질 수 있기 때문에 객관적이고 재현 가능한 런타임 측정을 생성 할 수 없습니다.
추가 비용없이 기존의 시간 기반 속도 리미터를 실행 된 WASM 명령어의 객관적인 추정치를 계산하는 리미터로 수정할 수 있음을 알았습니다. 이것은 Ethereum이 가스 소비를 측정하는 것과 유사합니다. 이 새로운 객관적 측정을 통해 속도 제한 대역폭과 마찬가지로 CPU를 제한 할 수 있습니다.
블록 제작자는 네트워크 대역폭과 함께 사용하는 CPU 사용량과 동일한 "동적 초과 구독"알고리즘을 사용합니다. 즉, 네트워크에 여분의 CPU 용량이있는 동안 사용자는 완전한 정체 중에 얻을 수있는 것보다 많은 CPU 당 스테이크 토큰을 얻을 수 있습니다.
블록 생성자는 여전히 CPU 명령 카운팅 외에도 주관적인 런타임 제한을 구현합니다. 이 주관적 제한은 시간이 많이 소요되는 작업보다 시간이 많이 드는 작업을 사용하여 미터링 알고리즘을 남용하는 사람들로부터 네트워크를 보호합니다.
CPU와 네트워크 대역폭의 분리
이전 업데이트에서 우리는 CPU / 네트워크가 모두 대역폭의 일부로 간주되는 RAM, 저장소 및 대역폭을 분리하겠다고 밝혔습니다. Steem과 같은 일부 응용 프로그램은 높은 네트워크 대역폭 (게시물)과 낮은 CPU 대역폭을 가질 수 있지만 다른 응용 프로그램은 낮은 네트워크 대역폭 (교환 주문)을 가질 수 있지만 높은 CPU 대역폭 (순서 매칭)을 가질 수 있음을 알았습니다. 즉, 모든 사이즈의 가격 책정 및 / 또는 스테이징은 의미가 없습니다.
일을 간단하게 유지하기 위해 사용자 인터페이스는 일반 사용자를 위해 이러한 것들을 함께 묶을 수 있습니다. 그러나 고급 사용자는 가격 유연성이 향상되었습니다.
트랜잭션 압축
C ++ STL 라이브러리에 대한 지원을 추가하는 과정에서 우리는 현명한 계약이 상당히 큰 (50kb) 것을 알았으므로 상당한 네트워크 대역폭을 소비하게됩니다. 더 복잡한 계약이 200kb 이상으로 커질 수도 있습니다. 우리는 또한 Steem과 같은 많은 애플리케이션이 매우 압축 가능한 컨텐트를 트랜잭션으로 묶음을 깨달았습니다.
우리는 스마트 계약 업로드에 대해 대역폭 사용을 60 % 이상 줄이고 Steem과 같은 콘텐츠를 더 많이 제공 할 수있는 트랜잭션의 zlib 압축에 대한 지원을 추가했습니다.
네트워크 업데이트
P2P 네트워크 팀은 성능과 안정성을 향상시키기 위해 코드를 업데이트하는 중입니다. 이번 주 그들은 다음과 같은 점에서 중요한 진전을 이루었습니다.
블록 요약 - 블록이 브로드 캐스트되는 경우 블록의 모든 트랜잭션을 다시 전송하지 않고 트랜잭션 ID 만 포함됩니다. 이렇게하면 대역폭 사용을 거의 50 %까지 줄일 수 있습니다.
대용량 메시지 지원 - 대용량 메시지 (50kb 스마트 계약과 같은)를 방송하려면 작은 메시지 (예 : 200 바이트 전송)와 다른 네트워크 프로토콜이 필요합니다.