지난주, 이전에는 EOS로 알려졌던 Vaulta의 노드 운영자들이 모여 중요한 업데이트에 대해 논의했습니다. 회의에서는 Antelope Spring 2.0 소프트웨어의 진행 상황, 블록 프로듀서 연결을 위한 새로운 가십 시스템 작동 방식, 그리고 네트워크 연결을 더 안전하게 만드는 아이디어에 대해 다루었습니다. 노드 운영자들은 Vaulta 블록체인을 원활하게 운영하면서 기술적인 문제와 네트워크 설정 방식에 대한 경험을 공유했습니다.
주요 내용
-
Antelope Spring 2.0의 개발자 미리보기 1이 출시되었으며, 동기화 호출에 중점을 두었고, 9월경에 미리보기 2에서 더 중요한 변경 사항이 예상됩니다.
-
새로운 이벤트 시스템은 노드 운영자에게 저장 공간 제한을 설정하도록 요구할 것이며, 개발이 진행됨에 따라 더 자세한 내용이 제공될 것입니다.
-
가십 피어링 시스템의 채택이 진행 중이지만, 모든 주요 블록 프로듀서가 아직 연결된 것은 아니므로 네트워크가 완전히 메시화되지 않았습니다.
-
가십 네트워크 설정은 어려웠으며, 피어 찾기 문제가 있었고, 새로운 노드가 연결하는 데 도움이 되도록 호스팅된 목록을 사용할 것을 제안했습니다.
-
새로운 아이디어는 노드 운영자가 가십 시스템에 허용되거나 차단된 피어 목록을 생성하여 연결 및 보안 관리를 돕는 것입니다.
Antelope Spring 2.0 개발 진행 상황
Antelope Spring 2.0 개발이 진행 중이며, 첫 번째 개발자 미리보기(DP1)가 출시되었습니다. 이 초기 릴리스는 동기화 호출을 지원하고 테스트넷 환경에 대한 접근을 제공합니다. 개발자들은 CDT 5.0 dev 1.1을 사용하여 계약을 재구축하도록 요청받고 있습니다. 현재 DP1은 노드 운영자에게 큰 변화를 주지 않으며, 더 큰 영향은 DP2에서 예상됩니다. 다음 미리보기인 DP2는 9월 초에 예정되어 있으며, 새로운 이벤트 시스템과 함께 속도 개선이 포함될 것입니다.
이벤트 시스템 미리보기 및 영향
Antelope Spring 2.0의 다가오는 개발자 미리보기 2(DP2)는 새로운 이벤트 시스템을 도입할 예정입니다. 이 시스템은 합의 데이터 내에서 암호학적으로 커밋되는 임시 이벤트를 브로드캐스트할 수 있게 합니다. 노드 운영자에게 이는 새로운 구성 매개변수가 도입되어 이러한 이벤트에 대한 최소 저장 설정을 지정해야 함을 의미합니다. 이러한 이벤트를 관리하기 위한 정확한 세부 사항과 모범 사례는 개발이 진행됨에 따라 여전히 작업 중이지만, DP2는 이를 처리하는 데 필요한 초기 노드 관련 기능 및 구성을 제공할 것입니다. 노드 운영자에게 미치는 영향은 상당하며, 이 새로운 데이터 스트림을 수용하기 위해 구성을 조정해야 할 것입니다.
이벤트 시스템 기능
-
이벤트는 임시 메시지입니다.
-
이벤트는 합의 내 암호화 커밋을 통해 보호됩니다.
-
노드 운영자는 저장 제한을 정의해야 합니다.
노드 운영자를 위한 구성 요구 사항
-
임시 이벤트에 대한 최소 저장 공간을 설정합니다.
-
이벤트 데이터 흐름을 모니터링합니다.
-
DP2의 새로운 구성 매개변수에 적응합니다.
이벤트 시스템의 예상 영향
-
관리해야 할 새로운 데이터 유형.
-
향상된 네트워크 모니터링 가능성.
-
업데이트된 운영 절차의 필요성.
가십 BP 피어링 채택 현황
여러 상위 블록 프로듀서(BP)들이 피어 키를 등록하는 조치를 취했으며, 이는 좋은 시작입니다. Genereos와 Eosphere 사이와 같이 부분적인 피어링 연결이 이루어지고 있으며, 이는 일부에서 기본 연결 기능이 작동하고 있음을 보여줍니다. 그러나 이것이 아직 전체 네트워크에서 일어나고 있지는 않습니다. 채택은 여전히 진행 중이며, BP들의 더 많은 조정과 명확한 확인이 상황을 가속화하는 데 큰 도움이 될 것입니다. 우리는 아직 중요한 채택 수준에 도달하지 못했으며, 이것이 가십 네트워크가 예상대로 완전히 메시화되지 않은 이유일 수 있습니다.
가십 네트워크 형성의 기술적 과제
블록 프로듀서(BP)를 위한 안정적인 가십 네트워크를 설정하는 것은 생각보다 간단하지 않습니다. 몇 가지 난관에 부딪히고 있습니다. 우선, 다른 피어를 찾는 것이 복불복입니다. 이는 종종 일부 BP가 구성을 완전히 정리하지 않았거나, 방화벽이 연결을 차단하여 방해가 되기 때문입니다. 이는 때때로 노드가 서로를 볼 수 있어야 할 때 볼 수 없다는 것을 의미합니다.
현재 상황을 시작하기 위해 사람들은 연결을 부트스트랩하기 위해 피어를 수동으로 추가할 것을 제안하고 있습니다. 이것은 작동하지만, 자체적으로 길을 찾아야 하는 분산 시스템에는 이상적이지 않습니다. 새로운 노드가 기존 노드를 찾는 데 도움이 되는 "시드 피어" 시스템과 같이 노드가 서로를 자동으로 발견할 수 있는 방법이 부족합니다. 떠도는 아이디어 중 일부는 이 초기 설정을 돕기 위해 호스팅된 JSON 피어 목록을 사용하는 것을 포함합니다.
가십 연결을 위한 제안된 화이트리스트/블랙리스트 기능
가십 네트워크 내 연결 관리를 돕기 위해 피어의 화이트리스트 및 블랙리스트를 허용하는 기능이 고려되고 있습니다. 이는 노드 운영자에게 다른 노드와 연결할 수 있는 더 많은 제어권을 제공할 것입니다. 이 아이디어는 운영자가 연결을 허용하거나 금지할 특정 블록 프로듀서(BP) 계정을 지정할 수 있도록 하는 것입니다.
이 제안된 시스템은 기존 수동 피어 구성과 함께 작동할 것입니다. 노드 구성에 수동으로 추가하는 모든 피어는 여전히 우선순위가 부여됩니다. 그러나 가십 프로토콜을 통해 발견된 피어의 경우 화이트리스트 및 블랙리스트 규칙이 적용됩니다.
이 기능의 주요 목표는 오작동하거나 어떤 형태의 공격을 받고 있는 노드와의 연결을 방지하는 방법을 제공하는 것입니다. 이는 운영자가 들어오는 가십 트래픽을 필터링하기 위해 복잡한 외부 방화벽 규칙을 관리할 필요성을 줄이는 방법으로 간주됩니다.
다음은 작동 방식에 대한 분석입니다.
-
화이트리스트: 가십을 통해 노드에 연결하는 것이 명시적으로 허용된 특정 BP 계정 목록입니다.
-
블랙리스트: 가십을 통해 노드에 연결하는 것이 명시적으로 금지된 특정 BP 계정 목록입니다.
-
기본 동작: 화이트리스트나 블랙리스트가 구성되지 않았거나 피어가 어느 목록에도 없는 경우, 노드는 기본 연결 동작을 따르며 잠재적으로 연결을 허용할 것입니다.
피어 식별 및 남용 완화에 대한 우려
피어 식별 문제
가십 시스템의 주요 걱정 중 하나는 누가 실제로 무엇을 보내고 있는지 파악하는 것입니다. 메시지가 다른 노드를 통해 전달될 수 있기 때문에, 문제가 되는 트래픽이 실제로 어디에서 시작되었는지 추적하기 어렵습니다. 이것은 문제의 근원을 차단하기 어렵게 만듭니다. 문제를 일으키는 노드 하나를 차단하더라도, 아직 식별하지 못한 다른 노드를 통해 계속 확산될 수 있습니다. 이는 두더지 잡기 게임과 비슷하게 느껴지며, 원래 발신자가 누구였는지 확실히 알 수 있는 쉬운 방법이 없습니다.
남용 완화 전략
이 문제를 해결하기 위해 사람들은 누가 연결할 수 있고 어떤 종류의 트래픽이 허용되는지에 대한 더 나은 제어 방법을 요구하고 있습니다. 이는 단순한 차단 이상의 것을 의미합니다. 피어의 신원을 확인하고 규칙을 더 신중하게 적용할 수 있는 시스템이 필요합니다. 현재 설정은 이러한 종류의 세부적인 제어를 제공하지 않으며, 이는 네트워크를 깨끗하고 안전하게 유지하는 데 큰 장애물입니다. 네트워크가 정보를 너무 자유롭게 전달하도록 설계되었을 때 개별 노드를 차단하는 것만으로는 충분하지 않다는 것이 분명합니다.
기능 실현 가능성에 영향을 미치는 네트워킹 제약
새로운 기능을 작동시키는 것을 고려할 때, 특히 가십 연결을 위한 제안된 화이트리스트 및 블랙리스트와 같은 것들은 실제 네트워킹 문제에 부딪힙니다. 단순히 스위치를 켜는 것만큼 간단하지 않습니다. 예를 들어, 많은 노드가 프록시 서버를 사용하여 연결합니다. 이는 매우 일반적이지만, 연결의 원래 IP 주소가 숨겨진다는 것을 의미합니다. 이는 트래픽이 어디에서 오는지 정확히 알기 어렵게 만들며, 누가 연결할 수 있는지 제어하려는 경우 큰 문제입니다.
그리고 기본 기술 자체도 문제입니다. 가십이 사용하는 TCP 프로토콜은 HTTP와 같은 다른 프로토콜처럼 누가 연결하는지에 대한 세밀한 제어를 제공하지 않습니다. 이는 상세한 정보를 기반으로 특정 연결을 허용하거나 차단하는 규칙을 쉽게 설정할 수 없다는 것을 의미합니다. 또한, 동적 IP 주소와 이러한 다양한 프록시 설정으로 인해 엄격한 화이트리스트 또는 블랙리스트를 적용하는 것은 정말 골치 아픈 일이 됩니다. 마치 끊임없이 따라잡기 게임을 하는 것 같습니다.
이러한 문제 때문에 많은 노드 운영자들은 전통적인 방화벽 수준의 제어가 여전히 네트워크 트래픽을 관리하는 가장 실용적이고 효과적인 방법이라고 생각합니다. 그들은 이에 익숙하며, 가십 특정 기능만큼 통합적이지 않더라도 안정적으로 작동합니다. 제안된 기능이 이러한 기존 네트워킹 현실을 정말로 극복할 수 있는지, 아니면 핵심 문제를 해결하지 않고 복잡성만 더할 것인지 고려해야 합니다.
결론 및 다음 단계
Antelope Spring 2.0의 개발, 특히 다가오는 개발자 미리보기 2(DP2) 및 통합 이벤트 시스템은 향후 노드 운영자 테스트 및 피드백을 위한 중요한 영역을 나타냅니다. 블록 프로듀서(BP) 피어링을 위한 가십 프로토콜 채택을 장려하고 모니터링하는 지속적인 노력 또한 중요합니다. 가십 연결 관리를 위한 제안된 화이트리스트 및 블랙리스트 기능은 잠재적으로 유용한 도구로 인정되었지만, 현재의 한계로 인해 네트워크 보안을 위한 완전한 해결책은 아닙니다. 이러한 기능 구현의 실제적인 실현 가능성과 효과를 평가하기 위해 추가 연구 및 커뮤니티 의견이 수렴될 것입니다.
운영자를 위한 주요 중점 영역
-
DP2 및 이벤트 시스템: 노드 운영자는 이러한 구성 요소가 사용 가능해지면 테스트를 준비해야 합니다.
-
가십 피어링 채택: 더 강력한 가십 네트워크를 구축하기 위해 지속적인 참여와 성공적인 피어링 확인이 장려됩니다.
-
보안 기능 피드백: 제안된 화이트리스트/블랙리스트 메커니즘 및 기타 보안 문제에 대한 의견을 제공하는 것은 향후 개발을 형성하는 데 도움이 될 것입니다.
향후 고려 사항
-
가십 네트워크 견고성: 피어 발견 및 연결 안정성의 과제를 해결하는 것이 여전히 우선순위입니다.
-
신원 및 남용: 가십 네트워크 내에서 남용을 식별하고 완화하기 위한 더 효과적인 방법 개발에는 추가 조사가 필요합니다.
-
네트워킹 현실: 새로운 기능을 설계할 때 IP 마스킹 및 기존 네트워크 인프라와 관련된 실제적인 제약을 신중하게 고려해야 합니다.
이 기사는 AI 기반 기술의 지원을 받아 여러 신뢰할 수 있는 출처를 바탕으로 작성되었습니다. 최종 콘텐츠는 BlockzHub 편집팀에 의해 철저히 검토 및 편집되어 정확성, 명확성, 일관성을 보장합니다. 원본 보도 자료는 필요에 따라 적절히 출처를 명시합니다. 본 기사에 표현된 의견은 반드시 BlockzHub의 공식적인 견해나 입장을 반영하는 것은 아닙니다. 이 기사는 정보 제공 목적으로만 제공되며, 금융 또는 전문가의 조언으로 간주되어서는 안 됩니다. 투자는 위험을 수반하며, 투자 결정을 내리기 전에 반드시 자격을 갖춘 금융 전문가와 상담하시기 바랍니다.