EOSIO의 커뮤니티 포크는 현재 “Antelope”로 알려져 있습니다.

Antelope 프로토콜은 nodeos 소프트웨어 버전 2.0에서 구현된 이전 버전의 EOSIO 프로토콜에서 분기되었습니다.

Mandel 3.1 은 이제“Leap 3.1”입니다.

이전 EOSIO 프로토콜의 주요 C++ 구현에는 고유한 이름이 부여되지 않아 프로토콜 자체에 대해 논의하는지 아니면 프로토콜의 특정 구현에 대해 논의하는지에 대해 혼란을 야기했습니다. 이 모호성은 Antelope 프로토콜의 첫 번째 커뮤니티 실행 구현인 Leap v3.1로 해결되었습니다.

이러한 변경들로 이어진 이벤트들에 대한 요약은 다음 문서를 참조하시기 바랍니다:

커뮤니티-실행 프레임워크를 통한 새로운 시대의 시작 — Antelope!

9월 21일 컨센서스 업그레이드를 위한 준비

2022년 9월 21일 수요일, EOS 블록 프로듀서들은 Leap 3.1로 조정된 컨센서스 업그레이드를 실행하여 자기 결정을 향한 새로운 길을 개척하기 시작할 것입니다.

노드를 실행하는 모든 사용자는 네트워크와 동기화를 유지하려면 9월 21일 이전에 노드를 업그레이드해야 합니다.

Leap 3.1 릴리스에 대한 조정된 컨센서스 업그레이드에는 네트워크 컨센서스에 따라 안내되는 우선 순위가 포함됩니다. 이번 릴리스에서 EOSIO 네트워크 연합은 이전의 무관심했던 EOSIO 개발자들을 EOS 네트워크 재단(ENF) 핵심 개발 팀으로 공식적으로 교체합니다. 이러한 해방은 크로스 체인 협업을 가능하게 하고 네트워크를 미래로 나아가게 합니다.

Leap 업그레이드는 자체 코드베이스의 소유권을 가정하는 네트워크를 나타냅니다.

네트워크의 수호자로서, EOS의 블록 프로듀서들은 안정적인 네트워크 업그레이드를 책임지고 있습니다. 그러나 컨센서스 업그레이드와 함께 네트워크의 모든 노드는 업데이트 되어야 합니다.

지금까지 몇 주 동안 많은 사람들이 Leap 3.1을 테스트해 왔으며 ENF 엔지니어링 팀은 정기적으로 릴리스 후보들을 푸쉬해 왔습니다. 이 테스트는 개발자들이 향후 출시될 예정인 Leap 3.1 및 관련 소프트웨어에 대한 마무리 작업을 진행함에 따라 계속됩니다.

이전 EOSIO 1.8 릴리스와 마찬가지로, Leap 3.1은 원활한 네트워크 컨센서스 업그레이드를 위해 블록 프로듀서들과 다른 네트워크 참가자 간의 조정이 필요합니다. 소프트웨어가 릴리스되면, 노드 운영자는 바이너리 업데이트 전에 전체 조건들을 검증하고 사용되지 않는 플러그인을 제거하고 구성 설정을 변경해야 합니다.

이 문서는 노드 업그레이드 프로세스를 용이하게 하고 작업 중단을 방지하기 위한 업그레이드 체크리스트를 제공합니다. 일부 특정 단계들은 기존 노드 구성에 따라 다를 수 있지만 이러한 일반 단계들은 대부분의 노드에서 작동합니다.

개발자들은 설문지 양식(설문 조사 질문)을 작성하여 가장 많이 사용되는 API 노드를 결정하고 리소스의 우선 순위를 지정할 수 있습니다.

ENF가 최종 릴리스를 공개하면, 노드 운영자는 Leap로 업그레이드할 수 있습니다. 최종 Leap 3.1 릴리스는 GitHub에서 확인할 수 있습니다. 이전 버전들은 릴리스 페이지에 있습니다.

업그레이드 계획:

  1. 프로덕션 노드에서 수행하기 전에 테스트 서버에서 이러한 단계들을 수행할 수 있는지 확인해 보시기 바랍니다.
  2. 지원되는 운영 체제 중 하나를 사용해 보시기 바랍니다(Ubuntu 18.04, 20.04, 22.04). 새로운 서버에 Leap 3.1을 설치하거나 기존 서버를 업그레이드할 수 있습니다. 지침서들은 여러분들이 업그레이드 중인 것으로 가정합니다.
  3. 미리 빌드된 바이너리를 사용할지, 아니면 스스로 바이너리를 컴파일 할지를 결정합니다.(세부사항)
  4. 노드가 Leap 3.1에서 더 이상 사용할 수 없는 플러그인을 사용하도록 구성되지 않았는지를 확인합니다(Leap 3.1 릴리즈 페이지 및 코드명 Mandel 릴리스의 사용 중단에 명시된 대로).

이러한 플러그인들을 사용하는 노드는 활성화하기 전에 이상적으로 즉시 그들의 솔루션들을 조정해야 합니다 :

  • History v1 “history_plugin” + “history_api_plugin”
  • MongoDB “mongo_db_plugin”

운영자는 솔루션들을 Hyperion 또는 Chronicle과 같은 서비스로 마이그레이션할 수 있습니다. 추적 기록 플러그인(trace history plugin)은 기본 마이그레이션 옵션입니다.

이때, 여러분들이 스냅샷으로 2.0(2.1이 아님) 노드를 업그레이드하는 경우, 업그레이드를 위한 준비로 이동할 수 있습니다.

  1. EOSIO 2.1은 Leap와 호환되지 않는 SHiP(State History Plugin) 파일과 blocks.log 파일을 사용했습니다. 2.1의 SHiP 파일은 항상 3.1과 호환되지 않습니다. 그러나 노드가 이전 버전의 EOSIO에서 업그레이드된 경우, block.log 파일이 호환될 수 있습니다.
    Leap 3.1은 EOSIO 2.0 기반이며, 따라서 노드를 EOSIO 2.0에서 업그레이드하는 것은 간단합니다.
만약 여러분들이 EOSIO 2.1을 사용하는 경우에는 추가 작업이 있을 수 있습니다:
  1. blocks.log 파일이나 상태 히스토리(state history)를 유지하지 않는 2.1 노드들은 업그레이드 하기 가장 쉽습니다. 단지 스냅샷에서 노드를 시작하면 됩니다.
  2. blocks.log 파일은 유지하지만 상태 히스토리를 유지하지 않는 2.1 노드의 경우, blocks.log 파일의 버전이 중요합니다. block.log가 EOSIO 2.1 이전에 생성된 경우, block.log 파일은 3.1과 호환되며, 여러분들은 기존 block log들을 제거하지 않고 스냅샷에서 시작할 수 있습니다.
    1. EOSIO 2.0을 사용하시는 경우 여러분의 block log는 호환 가능합니다.
    2. EOSIO 2.1을 사용하시는 경우, 여러분의 block log는 호환될 수도 있고 호환되지 않을 수도 있습니다. 호환 불가능한 block.log파일은 제거되어야 합니다. 여러분의 노드가 Unbuntu 22.04에서 실행중인 경우에는 여러분의 block.log 파일이 호환되는지를 확인하기 위해, 다음 명령어를 사용하시기 바랍니다 :

      apt install bsdextrautils
      hexdump <nodeos data directory>/blocks/blocks.log | head

      만약 여러분의 노드가 Unbuntu 20.04에서 실행중인 경우, 다음 명령어를 사용하시기 바랍니다:
      apt-get install bsdmainutils
      hd <nodeos data directory>/blocks/blocks.log | head

      (<nodeos data directory> 는 노드들이 블록체인 데이터를 저장하는 “데이터” 디렉토리입니다. 예를 들어, “.local/share/eosio/nodeos/data”가 될 수 있습니다.)

      출력 값의 두 번째 숫자(맨 윗 행의 왼쪽에서 두 번째 열)은 blocks.log 버젼을 나타냅니다. 0001, 0002, 혹은 0003 이면 괜찮습니다. 0004는 EOSIO 2.1을 의미하며, 이는 호환되지 않습니다.

      0000000 0003 8000 6a7f 017e e473 5a38 0827 d7e6
      0000010 8804 fb34 07c1 2f9f b1ab 3c7b 5b12 6a14

      출력이 계속됩니다. 굵게 표시된 부분 외에는 내용이 다를 것입니다.
  3. 만약 여러분의 노드가 EOSIO 2.0을 실행 중이며 블록과 상태 히스토리를 유지해야 하는 경우, 여러분은 업그레이드를 위해 스냅샷을 사용할 수 있습니다.
  4. 만약 여러분의 노드가 EOSIO 2.1을 실행 중이며 상태 히스토리를 유지해야 하는 경우, block log를 리플레이 하거나 네트워크로부터 다시 동기화해야 합니다. 네트워크 오버헤드를 줄이기 때문에, 리플레이가 더 빠릅니다.
    1. 만약 여러분이 blocks.log의 호환되는 버젼을 가지고 계신 경우, 여러분의 blocks log를 리플레이할 수 있습니다. 위의 (2.2)를 참고해주시기 바랍니다. 리플레이는 몇 주가 소요될 수 있습니다.
    2. 여러분의 블록 로그가 호환되지 않는 경우, 네트워크의 다른 노드에서 다시 동기화해야 합니다. 2.0 또는 2.1에서 동기화할 수 있으며, 다시 동기화하면 호환되는 blocks.log 파일이 생성됩니다. 재동기화에는 몇 주가 소요될 수 있습니다. 다시 동기화할 때 blocks.log와 상태 히스토리가 함께 생성됩니다.
      다운로드를 위해 2.0 blocks.log 파일을 요청하고자 하시는 경우, EOS Support에 문의해 주시기 바랍니다.

그림 1, 구성에 따라 2.1을 실행하는 노드가 수행해야 하는 단계 표
(노란색과 빨간색으로 강조 표시된 셀은 완료하는 데 몇 주가 걸릴 수 있는 단계를 나타냅니다)

업그레이드 프로세스에 대한 질문이 있는 경우 EOS Support로 문의해 주시기 바랍니다.

업그레이드를 위한 노드 준비

  • Leap을 설치하기 위해 미리 빌드된 바이너리를 다운로드합니다. Leap을 직접 구축하고자 하는 운영자는 readme에서 지침을 찾을 수 있습니다.
  • 필요한 경우, 바이너리를 설치하기 전에 호환 가능한 스냅샷이 있는지 확인해 보시기 바랍니다.
    • EOSIO 2.0(EOSIO 2.1 아님)을 실행 중인 경우 다음 명령을 사용하여 로컬 노드 내에서 스냅샷을 생성할 수 있습니다:

      curl -X POST http://127.0.0.1:8888/v1/producer/create_snapshot

      스냅샷 수행을 위해, 노드는 반드시 구성 옵션 플러그인과 함께 시작되어야 합니다 = eosio::producer_api_plugin

      Producer_api_plugin은 관리자 전용이므로 활성화 시 노드가 공개되지 않도록 주의해 주시기 바랍니다.
    • 처음부터 블록체인 히스토리를 리플레이 하는 것은 스냅샷 사용에 대한 대체수단입니다. 하지만 이는 완료까지 몇 주가 소요됩니다.
  • 몇몇 구성 옵션들은 변경되었습니다. 만약 유효하지 않은 구성 옵션들이 있을 경우, Nodeos는 시작되지 않을 것입니다.
    • Reversible Block Database 구성이 제거되었으며 운영자는 config.ini 및 기타 스크립트에서 다음 매개변수들을 제거해야 합니다.
      • reversible-blocks-db-size-mb 
      • reversible-blocks-db-guard-size-mb 
      • fix-reversible-blocks 
      • import-reversible-blocks
      • export-reversible-blocks
    • nodeos 2.1의 Block log splitting 기능이 제거되고 log block rotation으로 변경되었습니다. 다음의 매개변수들을 제거하시기 바랍니다::
      • blocks-log-stride
      • max-retained-block-files
      • blocks-archive-dir
    • 그리고 그들을 다음으로 대체하시기 바랍니다:
      • block-log-retain-blocks 
  • 현재 EOSIO 2.1을 실행하는 모든 노드는 상태 히스토리를 제거해야 합니다.
    • 데이터 디렉토리로부터, 다음을 사용하여 /state-history 디렉토리에서 파일들을 삭제하시기 바랍니다.
      rm <nodeos data directory>/state-history/*
  • 2.1의 블록 로그 버전 0004가 있는 모든 노드는 Block log를 제거해야 합니다.: 
    • 데이터 디렉토리로부터, 다음을 사용하여 /blocks 디렉토리에서 파일들을 삭제하시기 바랍니다.
      rm <nodeos data directory>/blocks/*
      rm <nodeos data directory>/blocks/reversible/*

다음의 설치는 스냅샷을 사용합니다. SHiP 또는 block log들에 대한 트랜잭션을 다시 리플레이 해야 하는 노드 운영자는 리플레이가 완료되는데 몇 주가 소요될 수 있음을 알고 있어야 합니다.

block.log 파일들의 재동기화 속도를 향상시키기 위한 참고 사항(2.1 노드의 경우):

  • 기본적으로 nodeos는 한 번에 100개의 블록을 동기화합니다. 네트워크가 안정적인 경우 한 번에 동기화되는 블록 수를 변경하는 –sync-fetch-span 옵션을 사용하여 잠재적으로 재동기화 속도를 높일 수 있습니다. 이 옵션은 대부분 비어 있는 블록에 특히 효과적입니다. 운영자는 숫자를 1000-5000으로 높게 설정했다고 보고했습니다. 재동기화가 완료되면 여러분은 이 숫자를 다시 100으로 설정해야 합니다.
  • 모든 피어에 첫 번째 블록이 포함된  blocks.log 파일이 있는 것은 아닙니다. 스냅샷에서 시작하는 노드는 blocks.log 파일에 사전 스냅샷 블록을 포함하지 않습니다. p2p 목록을 변경하여 재동기화 속도를 향상시킬 수 있습니다. 만약 여러분이 제네시스 블록이 있는 p2p 피어 노드만을 포함하면 동기화 프로세스 속도가 빨라집니다. 전체 blocks.log 파일을 포함하는 피어 노드 목록을 참조하십시오.
  • 여러분의 p2p-peer-address 목록을 짧게 유지하십시오. 이상적으로는 지리적으로 가장 가까운 3개 또는 4개의 노드로 제한하는게 좋습니다. 여러분은 반드시 제네시스 블록까지 확장되는 최소 2~3개의 노드가 있어야 합니다.
    재동기화할 때 nodeos는 모든 피어에서 동일한 블록 배치를 요청합니다. 이렇게 하면 재동기화 프로세스가 느려지며, 신뢰할 수 있는 피어에는 종종 필요하지 않습니다. 모든 피어가 아닌 제한된 수의 피어와 동기화하면 중복 데이터를 방지하여 동기화 속도가 빨라집니다. 자신이 있는 경우, 여러분은 동기화할 가장 가까운 단일 피어 노드를 선택할 수도 있습니다.
  • 여러분은 동일한 데이터 센터에 있는 단일 피어에서 빠르게 동기화할 수 있습니다. 이렇게 하려면 제네시스로 돌아가는 모든 블록을 포함하는 blocks.log로 기존 노드를 실행하십시오. Genesis 블록에서 Leap와 다시 동기화할 때 이 노드를 p2p 피어로 나열합니다. 모든 블록과 함께 여러분의 노드가 nodeos 2.1 또는 2.2를 실행하는 경우에도 여전히 과거 블록을 제공하는 데 사용할 수 있습니다.
    만약 여러분이 Leap v3.1을 현재 실행중인 노드와 같은 서버지만 다른 p2p 포트에서 실행하신다면, 동기화를 더욱 가속화할 수 있습니다. 이를 통해 재동기화를 시작할 때 여러분은 127.0.0.1:<p2p_port>에 있는 자신의 노드를 피어로 나열합니다. 새로운 /blocks 및 /state 디렉토리 세트와 리플레이를 위한 충분한 NVMe 또는 디스크 공간이 있는지 확인하십시오.
  • 만약 여러분이 기존 서버에 호환되는 blocks.log 파일(nodeos v2.0에서)이 있는 경우 block log를 업그레이드 중인 서버에 간단히 복사하기만 하면 됩니다. 또는 신뢰할 수 있는 공개 소스에서 차단 로그를 다운로드할 수 있지만, 이는 여러분 자신의 것을 사용하는 것보다는 위험합니다.

만약 여러분들이 이러한 방법 중 하나를 사용하여 동기화 속도를 높이는 경우, 예기치 않은 동작을 방지하기 위해 추후에 옵션을 기본 설정으로 되돌려야 합니다.

바이너리 업데이트

프로덕션 머신에서 단계들을 반복하기 전에 테스트 머신에서 이 단계들을 수행하시기 바랍니다.

  1. 새로운 Ubuntu 노드로 시작하거나 nodeos를 중지하고 이전 바이너리를 제거하여 기존 노드를 업데이트합니다. 이전 바이너리를 제거하기 위해, 일반적으로 다음을 사용할 수 있습니다:
    dpkg --remove <old-pkg-name>
  1. 상태 파일을 제거합니다. 이 디렉토리의 파일을 삭제하려면 다음을 사용할 수 있습니다:
    rm <nodeos data directory>/state/*
  1. 바이너리 업데이트
    1. GitHub 릴리스 페이지에서 최신 Ubuntu 바이너리 다운로드 합니다.
    2. 터미널 윈도우를 열고, dpkg -i filename.deb를 실행하고, filename.deb를 다운로드된 Ubuntu 패키지의 파일명으로 대체합니다.
  2. 스냅샷과 함께 nodeos를 시작합니다.

이러한 단계를 거친 후에, 노드는 9월 21일 프로토콜 활성화를 위한 준비가 됩니다.

시스템 컨트랙트 및 애플리케이션

Leap 설치 후, 노드 운영자들은 블록 프로듀서들이 새로운 기능들을 활성화할 수 있도록 준비됩니다. 활성화 후 어느 시점에서 블록 프로듀서들은 시스템 컨트랙트를 업데이트할 수 있습니다.

Leap의 새로운 기능은 강력한 UX 개선사항을 제공합니다. 그러나 개발자가 새로운 기능들의 이점을 활용하기 위해 앱을 업데이트하는 동안 시간 지연이 발생할 수 있으므로 사용자는 이러한 도구를 즉시 사용할 수 없을 것입니다.

Leap의 새로운 기능을 사용하기 위한 첫 번째 애플리케이션들은 대부분 Trust EVM 컨트랙트와 가장 인기가 많은 월렛일 가능성이 높습니다. 다른 애플리케이션들은 새로운 Leap 기능을 그들의 워크플로우에 통합하는 데 시간이 걸릴 것입니다. 소프트웨어 개발 키트(SDK)의 출시는 Leap 기능의 가용성을 가속화하지만, 채택에는 여전히 시간이 걸릴 것입니다.

추가 고려 사항

블록 프로듀서들은 Leap 3.1의 모든 새로운 기능을 동시에 활성화합니다. 문제가 발생할 가능성은 낮지만, 이러한 변화는 스마트 컨트랙과 dApp에 영향을 미칠 수 있습니다. 개발자는 Jungle4와 같은 공개 테스트넷을 사용하여 자신의 dApp들이 예상대로 계속 작동하도록 할 수 있습니다. 개발자들은 이러한 테스트 네트워크를 사용하여 새로운 Leap 기능을 테스트할 수도 있습니다.

CDT(Contract Development Toolkit)가 업그레이드되었으며 이 도구를 사용하는 모든 사용자는 다음과 같은 몇 가지 명칭 변경 사항을 알고 있어야 합니다:

  • CDT 3.1은 eosio-cpp를 cdt-cpp로 변경하여 사용하는 것 처럼, “eosio” 접두사를 “cdt”로 대체하기 위해 바이너리의 이름을 변경합니다.
  • CMake 프로젝트의 경우, find_package(eosio.cdt) 대신 find_package(cdt)를 사용합니다.

다음 릴리스에는 더 많은 명칭 변경 사항이 포함될 예정입니다.

결론

EOS 네트워크는 Leap 3.1 업그레이드를 직접 개발하고 자금을 지원했으며, 개발자들과 운영자들의 많은 제안들을 수용했습니다. 이번 릴리스는 EOSIO 코드베이스상에 구축된 체인들을 위한 새로운 개발 시대를 나타내며, 부주의한 스튜어드의 예측할 수 없는 수렁에 빠진 이래로 수년 후 견고한 기반을 향한 한 걸음의 전진을 나타냅니다. ENF의 초점과 방향, 그리고 블록 프로듀서들의 승인 및 컨센서스와 함께 EOS는 마침내 운명의 고삐를 쥐고 있습니다.

blocks.log file이 제네시스까지 확장되는 피어 노드 목록:

EOS:

  • eos.seed.eosnation.io:9876
  • peer1.eosphere.io:9876
  • peer2.eosphere.io:9876
  • p2p.genereos.io:9876

EOS Jungle4 Testnet:

  • peer1-jungle4.eosphere.io:9876
  • jungle4.seed.eosnation.io:9876
  • jungle4.genereos.io:9876
  • jungle.p2p.eosusa.io:9883

EOS Jungle3 Testnet:

  • peer1-jungle.eosphere.io:9876
  • jungle3.eossweden.org:59073
  • jungle3.eosrio.io:58012

EOS Kylin Testnet:

  • kylin.seed.eosnation.io:9876
  • peer1-kylin.eosphere.io:9876

EOS 네트워크

EOS 네트워크는 수수료가 거의 없는 트랜잭션의 결정론적 실행을 위한 저지연, 고성능, 확장 가능한 WebAssembly 엔진인 EOS VM으로 구동되는 3세대 블록체인 플랫폼으로 최적의 web3 사용자 및 개발자 경험을 가능하게 하기 위해 특별히 제작되었습니다. EOS는 EOS 네트워크 재단(ENF)을 통해 도구 및 인프라에 대한 다중 체인 협업 및 공공재 자금 조달의 원동력 역할을 하는 EOSIO 프로토콜의 플래그십 블록체인 및 금융 센터입니다.

EOS 네트워크 재단

EOS 네트워크 재단(ENF)은 EOS 네트워크의 성장과 발전을 장려하기 위해 재정 및 비재정적 지원을 조정하는 비영리 단체입니다. ENF는 EOS 네트워크의 허브이며, EOS의 조정된 미래를 계획하기 위해 긍정적인 글로벌 변화를 위한 힘으로 탈중앙화의 힘을 활용합니다.