Development status updates, external audit results and CoinNet test version opening plan

Published in

BOSagora

39 min readJan 27, 2022

개발 진행 현항, 외부 감사결과 및 CoinNet 테스트 버전 공개 계획

This monthly report, albeit tardy, comes packed with a lot of exciting updates. During the period from Friday, the 1st of October 2021 to Friday, the 21st of January 2022, the team has created 291 pull requests, 271 of which have been merged. This amount for 484 commits, and over 34,000 lines changes over 177 files. And that’s just for Agora! Our development team also works on multiple related project, including many libraries used by Agora (example here), as well as Agora’s API server, the wallet, the block explorer, and more.

The team uses Github releases to track stable releases, and deploy to our private TestNet. During that period of time, 10 releases were put out, the latest being v0.32.0. As usual, anyone can download a release from the Docker registry, however the team also provides native builds for Ubuntu 20.04 and MacOS 11 as of the latest release.

Below is a more detailed explanation of the items that our team worked on during those months. For an even more in-depth view, refer to releases between v0.23.1 (released October 1st) and v0.32.0 (released January 19th).

Highlights

External Audit Report

A main focus of ours was to address points raised during the security audit. They have now all been addressed, and during our last round of audit, SlowMist reported no vulnerability.

Some of the items reported but are now fixed, were related to (by order of importance) :

Cross-chain replay attack (e.g. propagating transactions from TestNet to CoinNet);
DoS (denial-of-service) vectors, such as how the transaction pool handles large amount of transactions;
Some code style recommendation;

Name registry in the BOSAGORA network

The “name registry” or “DNS server” is a term that has been present in a few dev reports already. It might not be clear what role it takes in the network, so before we go over recent improvements, we think best to give you a refresher.

The name registry is a component of every Agora node: It allows to associate a public key with one or more IP addresses. This is needed because, when a node requests to become a validator, they don’t provide their public IP — as it can change at any time. Hence, other members of the network need a way to contact said validator. That’s what the registry does.

Under the hood, the registry implements a full DNS server, from scratch. This has multiple advantages:

It uses a well-established protocol that is the backbone of today’s internet;
You can type a node address in your browser, or use it anywhere you would use google.com, and will be able to access the node;
It greatly simplifies interoperability with other services;
As mentioned, each Agora node has a registry. Nodes can be configured to make this registry public, providing a DNS server for other nodes to find validators they want to contact.

Following is a more detailed list of improvements to the registry:

Persistence & Integration into Agora

Before October, the name registry was a separate entity, configured independently, without persistence. Early in October, it has been integrated in Agora, allowing greater flexibility, enhanced peer verification, and enabling persistence.

Authenticated peers, validators, and the rest of the world

The registry used to work in a black-and-white fashion: Either a peer was a validator, and could register, or wasn’t a validator, and couldn’t register. However, as enrollments expire with time, this led to some undesirable jitter, both on the registry and Agora’s side. Hence, the registry was changed to first accept registrations if there was a pending enrollment (an enrollment in the pool), then simply to accept registration if the public key owned an UTXO which could be used as a stake in an enrollment. Agora hasn’t been fully updated to follow the same logic yet, but it should soon be done.

Multiple improvements to comply with the RFC, including EDNS(0)

The initial implementation of the name registry was simply an HTTP server. Later on, for Votera, the need to use a DNS server arose. The first foray into DNS land implemented the most basic features of a DNS server, leaving some missing. This included name compression, handling a few edge cases, and support for DNS extensions. Those have all been implemented and tested with various clients, to ensure that we follow the specification to the letter.

Support for AXFR

A great advantage that DNS provides over a bare HTTP server is built-in replication. One can set up the primary server to be Agora, and any secondary / caching server to be one of the commonly-available softwares, such as BIND9. In order to support this, our team implemented AXFR, allowing servers to share their zones with one another. The support, initially implemented in November, has recently (January) been extended to be limited to a set of whitelisted peers, as is the custom with DNS servers.

Realm, validators, flash zones

Each node, in its configuration, now contains a realm. This realm is the domain name under which the network will live. For example, for TestNet, the realm will be testnet.bosagora.io. Under this realm, the registry currently maintains 2 zones: validators, and flash. As the name suggests, the former is for validators to register, while the second will keep track of flash nodes. This also makes possible seeding in a fashion similar to Bitcoin (meaning a node only needs to know its realm to start its IBD — Initial Block Download). Those zones can live in the same registry, or be split among multiple ones.

Other Agora improvements

Besides the registry improvements, the team is constantly tweaking the code to make sure it works under any situation. Improvements are mostly of two natures: consensus improvements, where the consensus protocol is adjusted, and general improvements, where the consensus is the same but the nodes behave differently. One example of a consensus improvements is the addition of a chain ID, where the way that hashes are generated and changed to prevent transactions generated for TestNet to be propagated in CoinNet. On the other hand, a more generic improvement would be the use of exponential backoff in connections, as opposed to fixed-interval retries: exponential backoff will handle long downtimes / error better and provide a more “logical” behavior to a human observer than fixed-interval retries would.

The following list only includes consensus improvements, as they are the main improvements, and the general improvements are both too numerous and technical. If you are interested in more details, the list of releases contain both.

Introduce Chain ID

As mentioned earlier, one of the benefits of the audit was to introduce a chain ID. While no one should use the same key pair in TestNet and CoinNet, the new chain ID mechanism ensures that, even if one does, their messages cannot be copied from one network to the other.

Commons payout interval now working on TestNet

Our TestNet has a shorter block interval, and shorted validator cycle: blocks are produced ten times faster than in CoinNet, and nodes need to re-enroll a hundred times more often. In that context, all consensus constants are parameterized, allowing our team to quickly test a variety of scenarios. The initial implementation of commons payout had a bug that showed up in TestNet, in which the interval was not properly handling different block intervals, which is now fixed.

Changes in Block signature scheme

The block signature scheme has been designed to be additive: Using the pre-image scheme, nodes can do a Schnorr signature without much of the setup normally required by this technique. However, a critical vulnerability was discovered, which would have allowed an attacker to steal private keys of validators. The scheme was then changed to patch this vulnerability, while keeping the additive property. However, the scheme also provided the ability to reveal a misbehaving validator’s key should they sign more than one block for the same height. This is currently not possible anymore, but the team is looking for alternatives.

Block header has been changed to include pre-images

The block header was previously including two components, missing_validators and random_seed. The former was expected to be almost always empty (as it was the list of validators being slashed this block), while the latter was a hash that was a combination of pre-images. However, as the block itself depends on pre-images for its signature scheme, this created some issues with validators needing to request both pieces of data separately.

The block header has been changed to include pre-images, and derive missing validators and the random seed from it. The pre-images can still be compressed internally by validators, as one needs only to keep the last pre-images of an enrollment (sometimes less) to be able to re-build the entire list.

Time offset has been eliminated

At the time in which a block is externalized and fixed in the consensus parameter, the nodes derive at which height they need to be, based on their local time (within a margin of error). The genesis timestamp is another part of the consensus parameter. Thanks to multiple improvements in the externalization process, the time_offset that was previously in the block header to work around delay in externalizations have been removed.

Improved block conflict resolution

When presented with competing blocks and/or nominations, nodes (and validators) should prefer those with more enrollments, as a larger network leads to more safety. This notion has been introduced in the consensus protocol.

Freezing transaction have been restructured to include an explicit fee

Previously, freezing transactions that were slashed were done so implicitly, leading to implementation issues in the wallet. A new implementation makes slashing more explicit, and more visible to clients.

Nomination sizes are now limited

Nomination sizes now have an upper limit, meaning that the block size is now implicitly limited as well.

Enrollments now need to be signed using the target block height

When a node decides to enroll, they were gossiping a structure containing a few key infos. However, this enrollment could be delayed and not included at the right height, leading to reconciliation issues on the node side. Worse, in some cases, hostile peers could re-use enrollments under some rare circumstances to try to enroll a node without their knowledge. This most likely would lead to the node being slashed if it wasn’t online to notice. Enrollments are now signed based on the block height, meaning those enrollments are only valid for a certain target height.

CoinNet test version opening plan

We plan to open CoinNet test version to external contributors on February 16th prior to the official launch of CoinNet. When test version is made public, anyone can participate as a validator and see how the network works. The wallet and Block Explorer developed by BOSAGORA are also integrated to CoinNet test version and can be tested together.

We also plan to hold an event with the opening of CoinNet test version. Contributors who participate as validators or find and report bugs in the test version will be rewarded. Detailed information related to the CoinNet test version open event will be announced in a separate announcement shortly, so please stay tuned!

개발 진행 현항, 외부 감사결과 및 CoinNet 테스트 버전 공개 계획

2021년 10월 1일부터 2022년 1월 21일까지의 개발 진행 내역이 나와있는 이번 보고서에는 흥미로운 업데이트가 많이 포함되어 있습니다. 팀은 291개의 풀 요청을 생성했으며, 그 중 271개가 병합되었습니다. 또한 이 양에 대한 484개 커밋, 177개 파일에 대한 34,000개 이상의 라인이 변경되었습니다. 개발 팀은 Agora의 API 서버, 월렛(Wallet), 블록 익스플로러(Block Explorer) 등 뿐만 아니라 아고라에서 사용하는 많은 라이브러리를 포함하여 여러 관련 프로젝트에서도 작업하고 있습니다.

저희 팀은 Github release를 사용하여 안정적인 릴리스를 추적하고 비공개 TestNet에 배포합니다. 그 기간 동안 10개의 릴리스가 출시되었으며 최신 버전은 v0.32.0입니다. 평소와 같이 누구나 Docker 레지스트리에서 릴리스를 다운로드할 수 있지만 팀은 최신 릴리스로 Ubuntu 20.04 및 MacOS 11용 기본 빌드도 제공합니다.

아래는 저희 팀이 지난 몇 달간 작업한 항목에 대한 자세한 내용으로 v0.23.1(10월 1일에 출시됨)와 v0.32.0(1월 19일에 출시됨) 사이에 출시된 내용입니다.

Highlights

외부 감사보고서

저희 팀의 주요 목표는 보안 감사 중에 제기된 사항을 해결하는 것이었습니다. 현재는 모두 해결됐으며, 최종 감사에서 SlowMist로 부터 ‘취약점 없음’이라는 의견을 받았습니다.

지금은 수정되었지만 당시 보고된 항목들은 다음과 같습니다.(중요도순)

Cross-chain재생 공격(예: TestNet에서 CoinNet으로 트랜잭션 전파)
트랜잭션 풀이 대량의 트랜잭션을 처리하는 방식과 같은 DoS(서비스 거부) 벡터
일부 코드 스타일 권장 사항;

BOSAGORA 네트워크의 이름 레지스트리

“네임 공간” 또는 “DNS 서버”는 이미 몇번 개발 보고서에 (dev report) 나왔습니다. 네트워크에서 어떤 역할을 수행하는지 명확하지 않을 수 있으므로 최근 개선 사항을 살펴보기 전에 여러분에게 다시 한 번 복습할 시간을 갖고자 합니다.

네임 레지스트리는 모든 Agora 노드의 구성 요소입니다. Public Key를 하나 이상의 IP 주소와 연결할 수 있습니다. 노드가 검증자(validator)가 되기를 요청할 때 언제든지 변경될 수 있는 공개 IP를 제공하지 않기 때문에 필요하다고 봤습니다. 따라서 네트워크의 다른 멤버는 해당 검증인에게 연락할 방법이 필요합니다. 그것이 레지스트리가 하는 일이라고 보시면 됩니다.

내부적으로 레지스트리는 처음부터 완전한 (full) DNS 서버를 구현하기때문에 다양한 장점이 있습니다.

오늘날 인터넷의 기반인 프로토콜을 사용합니다.
브라우저에 노드 주소를 입력하거나 google.com을 사용하는 모든 곳에서 사용할 수 있으며 노드에 액세스할 수 있습니다.
다른 서비스와의 상호 운용성을 크게 단순화합니다.
언급했듯이 각 Agora 노드에는 레지스트리가 있습니다. 이 레지스트리를 공개하도록 노드를 구성하여 다른 노드가 연락하려는 missing validator를 찾을 수 있도록 DNS 서버를 제공할 수 있습니다.

레지스트리 개선 사항에 대한 자세한 목록은 다음과 같습니다.

지속성과 아고라와 통합

10월 이전에는 네임 레지스트리 지속성 없이 독립적으로 구성된 별도의 엔터티였습니다. 10월 초에 Agora에 통합되어 더욱더 유동적이고 피어 검증이 향상되었으며 지속성이 가능해졌습니다.

인증된 피어, 검증인과 온 세계

단순히 작동하던 레지스트리: 피어가 missing validator이고 등록할 수 있거나 missing validator가 아니어서 등록할 수 없었습니다. 그러나 등록이 시간이 지남에 따라 만료됨에 따라 등록 기관과 Agora 측 모두에서 바람직하지 않은 ‘지터’가 발생했습니다. 따라서 등록이 보류 중인 경우(풀에 등록) 먼저 등록을 수락한 다음 공개 키가 등록의 지분으로 사용할 수 있는 UTXO를 소유한 경우 등록을 수락하도록 레지스트리가 변경되었습니다. Agora는 아직 동일하게 따르도록 완전히 업데이트되지 않았지만 곧 완료될 것입니다.

EDNS(0)를 포함하여 RFC를 준수하기 위해 다양한 개선을

네임 레지스트리의 초기에 단순히 HTTP 서버였지만 나중에, Votera같은 경우에. DNS 서버를 사용해야 할 필요성이 생겼습니다. DNS 영역에 대한 첫 번째 진출은 DNS 서버의 가장 기본적인 기능을 구현되었는데 일부는 누락되었습니다. 이것이 이름 압축, 여러 극단적인 경우의 처리, DNS 확장 지원이 포함됩니다. 이것이 다양한 클라이언트와 함께 테스트를 했고 우리가 이런 사양을 따르도록 보장합니다.

AXFR을 위한 지원

베어 (a bare) HTTP 서버에 비해 DNS가 제공하는 가장 큰 장점은 기본 제공 복제입니다. 기본 서버를 Agora로 설정하고 모든 보조/캐싱 서버를 BIND9와 같이 일반적으로 사용 가능한 소프트웨어 중 하나로 설정할 수 있습니다. 이를 지원하기 위해 우리 팀은 서버가 서로 영역을 공유할 수 있도록 AXFR을 구현했습니다. 11월에 처음 구현된 지원은 최근(1월) DNS 서버의 사용자 지정과 마찬가지로 허용 목록에 있는 피어 집합으로 제한되도록 확장되었습니다.

영역(realm), missing validator, 플래시 영역

각 노드에는 이제 영역(realm)이 포함됩니다. 이 영역은 네트워크가 존재할 도메인 이름입니다. 예를 들어, TestNet의 경우엔 영역은 testnet.bosagora.io가 됩니다. 이 영역에서 레지스트리는 현재 missing validator와 플래시의 2개 영역을 유지 관리합니다. 이름에서 알 수 있듯이 전자는 검증자가 등록하는 것이고 후자는 플래시 노드를 추적합니다. 이것은 또한 비트코인과 유사한 방식으로 시딩( seeding)을 가능하게 합니다(즉, 노드는 IBD — 초기 블록 다운로드를 시작하기 위해 자신의 영역만 알면 됨). 이러한 영역은 동일한 레지스트리에 있거나 여러 영역으로 분할될 수 있습니다.

기타 아고라 개선 사항

레지스트리 개선 외에도 저희 팀은 어떤 상황에서도 원활하게 작동하는지 확인하기 위해 지속적으로 코드를 수정하고 있습니다. 개선 사항은 두 가지로 나눴습니다: 합의 프로토콜(consensus protocol)이 조정되는 합의 개선과 합의는 동일하지만 노드가 다르게 동작하는 일반 개선입니다. 예를 들어, 체인 ID의 추가할 수 있습니다. 여기서 해시(hash)가 생성되고 변경되어 TestNet에 대해 생성된 트랜잭션 (transaction)이 CoinNet에서 전파되는 것을 방지합니다. 반면에 고정 간격 재시도와 달리 연결에서 지수 백오프를 사용하는 것이 더 일반적인 개선 사항입니다. 지수 백오프는 긴 가동 중지 시간/오류를 더 잘 처리하고 고정된 것보다 인간 관찰자에게 더 “논리적인” 동작을 제공합니다. -간격 재시도는 가능합니다.

다음 목록에는 일반적인 개선 사항은 너무 많고 기술적인 이유로 주요 개선 사항인 합의 개선 사항만 포함되어 있습니다. 자세한 내용을 관심 있으시다면 릴리스 목록에 두 가지가 모두 포함되어 있습니다.

Chain ID의 소개

앞서 언급했듯이 감사 (audit)의 이점 중 하나는 체인 ID를 도입하는 것입니다. 아무도 TestNet과 CoinNet에서 동일한 키를 사용해서는 안 되지만, 그렇게 한다고 해도, 새로운 체인 ID 메커니즘은 한 네트워크에서 다른 네트워크로 메시지를 복사할 수 없도록 되어있습니다.

TestNet에서 작동하는 commons payout 간격

저희의 TestNet은 블록 간격(Block Interval)과 검증자 주기가 짧아졌습니다. 블록은 CoinNet보다 10배 빠르게 생성되고 노드는 100배 더 자주 재등록 해야 합니다. 이러한 맥락에서 모든 합의 상수는 매개변수화 되어 우리 팀이 다양한 시나리오를 빠르게 테스트할 수 있습니다. Commons payout의 초기 구현에는 간격이 다른 블록 간격을 적절하게 처리하지 않는 TestNet에 나타난 버그가 있었는데, 현재는 수정되었습니다.

블록 서명 체계의 변경 사항

블록 서명 체계는 추가되도록 설계되었습니다. 사전 이미지 체계를 사용하여 노드는 일반적으로 이 기술에 필요한 설정 없이도 Schnorr 서명을 수행할 수 있습니다. 그러나 해커가 검증자의 개인 키를 훔칠 수 있는 치명적인 문제점이 발견되었습니다. 그 다음에 가감성 (additive property)유지하면서 이 문제를 해결하도록 체계가 변경되었습니다. 그러나 이 계획은 또한 오작동하는 검증자의 키가 동일한 높이에 (same height) 대해 둘 이상의 블록에 서명할 경우 이를 공개할 수 있는 기능을 제공했습니다. 이것이 현재 불가능하지만 팀은 대안을 찾고 있습니다.

사전 이미지를 포함하도록 블록 헤더가 변경되었습니다.

블록 헤더(block header)는 이전에 두 개의 구성요소, 즉 missing_validators 과random_seed를 포함했습니다. 전자는 거의 항상 비어 있을 것으로 예상되는 반면(이 블록은 검증자 목록이 삭제되었기 때문) 후자는 사전 이미지의 조합인 해시였습니다. 그러나 블록 자체가 서명 체계를 위한 사전 이미지에 의존하기 때문에 검증자가 둘 다의 데이터를 별도로 요청해야 하는 문제가 발생했습니다.

블록 헤더가 사전 이미지를 포함하도록 변경되었으며 누락된 missing validator 이로부터 임의의 시드를 파생합니다. 사전 이미지는 전체 목록을 다시 작성할 수 있도록 등록 과정에 마지막 사전 이미지(때로는 더 적음)만 유지하면 되므로 missing validator에 의해 내부적으로 압축될 수 있습니다.

시간 오프셋이(time offset) 삭제되었습니다.

블록이 외부화되고 합의 매개변수에서 고정되는 시간에 노드는 로컬 시간을 기반으로 필요한 높이를 도출합니다(오차 범위 내에서). 제네시스 타임스탬프(genesis timestape)는 합의 매개변수의 또 다른 일부입니다. 외부화 프로세스의 (externalization process) 여러 개선 덕분에 이전에 외부화 지연을 해결하기 위해 블록 헤더에 있던 time_offset이 삭제되었습니다.

개선된 블록 충돌의 해결

경쟁하는 블록, 또는 후보가 제시될 때 노드과 검증자는 더 큰 네트워크가 더 많은 안전으로 이어지기 때문에 더 많은 등록이 있는 노드를 선호합니다. 이 개념은 합의 프로토콜에 도입되었습니다.

프리징 트렌젝션이 명확한 수수료를 포함하도록 재구성되었습니다.

이전에는 삭감된 거래를 프리징하는 것이 너무 암묵적으로 이루어지므로 지갑에서 구현 문제가 발생했습니다. 새로운 구현으로 슬래싱(slashing)이 더 명확해지고 클라이언트가 더 잘 보일 수 있습니다.

이제 추천 크기가 제한됩니다.

이제 후보 크기에 상한선이 있습니다. 즉, 블록 크기도 이제 암시적으로 제한됩니다.

이제 대상 블록 높이를 사용하여 등록에 서명해야 합니다.

노드가 등록하기로 결정했을 때 몇 가지 주요 정보가 포함된 구조에 대해 가시핑(gossiping a structure)을 하고 있었습니다. 그러나 등록이 지연될 수 있고 올바른 높이에 포함되지 않아 노드 측에서 조정 문제가 발생할 수 있습니다. 심지어 어떤 경우에는 피어가 자신도 모르게 노드를 등록하려고 시도하는 드문 상황에서 등록을 재사용할 수 있다는 것입니다. 이것은 주목할만한 온라인 상태가 아닌 경우 노드가 슬래시되는 것으로 이어질 가능성이 큽니다. 등록은 이제 블록 높이를 기반으로 서명 됩니다. 즉, 이러한 등록은 특정 목표 높이에 대해서만 유효합니다.

CoinNet test version 공개 계획

저희는 CoinNet 정식 론칭에 앞서 2월 16일에 외부 기여자에게 테스트 버전을 공개할 계획입니다. 테스트 버전이 공개되면 누구든 검증자로 참여하고 네트워크가 어떻게 작동하는지 확인할 수 있습니다. 저희가 개발한 지갑(Wallet)과 블록 익스플로러(Block Explorer)도 테스트 버전에 연동되어 함께 확인할 수 있습니다.

또한 CoinNet 테스트 버전 공개와 함께 이벤트를 진행할 계획입니다. 검증자로 참여하거나, 테스트 버전 검증 과정에서 버그를 찾아서 리포트하는 기여자들에게는 추첨을 통해 리워드를 제공할 예정입니다. CoinNet 테스트 버전 오픈 이벤트와 관련된 자세한 내용은 별도 공지를 통해 안내드릴 예정이니 많은 관심 부탁드립니다.

2021.10–2022. 01开发报告

活动日志

这份月度报告虽然有点晚，但包含了许多令人振奋的更新。在 2021 年 10 月 1 日星期五至 2022 年 1 月 21 日星期五期间，团队一共创建了 291 个拉取请求，其中 271 个已被合并。共有484 次提交，以多于34,000 行更改超过 177 个文件。这都只是为了 Agora！我们的开发团队还负责多个相关项目，包括使用许多 Agora藏库(示例)，以及 Agora 的 API 服务器、钱包、区块浏览器等。

团队使用 Github 版本来跟踪稳定版本，并部署在我们的个人测试网(TestNet)。在此期间共发布了 10 个版本，最新的是 v0.32.0。像往常一样，任何人都可以从 Docker 注册表下载一个版本，然而团队还提供了最新版本的 Ubuntu 20.04 和MacOS 11 的原始构建。

以下是对我们团队在这几个月中,工作的项目的更详细说明。如需更深入了解，请参阅 v0.23.1（10 月 1 日发布）和 v0.32.0（1 月 19 日发布）之间的版本。

Highlights

审计报告

我们的焦点之一为应对保安审计中提出的要点。然而, 所有问题都得已解决，根据SlowMist报告，于审计中并没有发现任何漏洞。

一些已报告且现已修复的项目如下（依重要性顺序）：

跨链重放攻击（例如，将交易由TestNet 轉移至 CoinNet）；
DoS（阻断服务）向量，例如交易池如何处理大量交易；
推荐一些代码风格；

BOSAGORA 网络中的名称注册

“名称注册表”或“DNS 服务器”这些專名詞已经出现在好幾份开发报告中。或許並不太清楚它在网络中擔當什么角色，因此在讨论近期的改进前，我们认为最好先复习一下。

名称注册表是每个 Agora 节点的组成部分：它允许将公钥与一个或多个 IP 地址連接。而这是必要的，因为当一个节点请求成为验证者时，他们不会提供他们的公共 IP, 而它亦能随时更改。因此，网络的其他成员需要联系该验证器的方法。这就是注册表的作用。

在后台，注册表从头开始实现了一个完整的 DNS 服务器。这有多个优点：

它使用了一个完善的协议，该协议是当今互联网的支柱；
可以在浏览器中输入节点地址，或者在 google.com 访问该节点；
它极大地简化了与其他服务的互操作性；

如前所述，每个 Agora 节点都有一个注册表。可以将节点配置为公开此注册表，为其他节点提供 DNS 服务器以查找他们想联系的验证者。

以下是注册表改进的更详细列表：

持久化和集成到 Agora

在 10 月之前，名称注册表是一个单独的实体，独立配置，亦缺乏持久性。 10 月初，它已集成到 Agora，提供更大的灵活性、增强的对等验证和持久性。

已认证的对等端、验证器和其他国家

注册表以前以黑白方式工作。对等端是验证器，可以注册，也可以不是验证器，不能注册。但是由于注册到期，注册表和 Agora 侧可能会出现一些不理想的抖动。因此，注册表在存在待定注册（在池中注册）时首先被变更为接受注册，如果公钥拥有可用于注册的 UTXO，则简单地接受注册。虽然Agora 尚未完全更新以遵循相同的逻辑，但须尽快完成。

多项改进以符合 RFC，包括 EDNS(0)

名称注册表的初始实现只是HTTP服务器。此后，Votera需要使用DNS服务器。首次入侵DNS LAND时，DNS服务器的最基本功能已实现，但部分功能仍丢失。包括: 名称压缩、处理一些边缘情况以及对 DNS 扩展的支持。这些都通过各种客户端进行实施和测试，确保客户端按照规范进行。

支持 AXFR

与 BareHTTP 服务器相比，DNS 提供的一个巨大优势是内置复制。可以将主服务器设置为 Agora，将任何辅助/缓存服务器设置为常用软件之一，例如 BIND9。为了支持这一点，我们的团队实施了 AXFR，允许服务器彼此共享其区域。该支援最初于 11 月实施，最近（1 月）已扩展到仅限于一组白名单对等方，就像 DNS 服务器的自定义一样。

Realm(移动数据库)、验证者、闪存区

每个节点在其设置中都包含一个realm(移动数据库)。这个realm是网络生存的域名。例如，对于 TestNet，realm为 testnet.bosagora.io。在此realm中，注册表当前保留两个区域: 验证器和闪存。如名称所示，前者用于验证器注册，后者用于跟踪闪存节点。这也可以以类似于比特币的方式进行seeding（也就是说，节点只需知道其realm即可启动 IBD-Initial Block Download）。这些区域可以位于同一注册表中，也可以分割为多个注册表。

其他 Agora 改进

除了注册表改进外，团队还不断修改代码，以确保在任何情况下都能正常工作。改进主要包括两种性质:协议改进（调整协议协议）和一般改进（协议相同但节点行为不同）。改进的其中一个示例为添加Chain ID。在此示例中，更改了生成散列的方式，以防止TestNet 生成的交易转移至 CoinNet 中。另一方面，与固定间隔重试相比，更普遍的改进是利用指数退避(Exponential backoff )来连接。指数退避能更完善地处理长时间的停机时间或错误，并且比固定间隔重试更具”逻辑”地供人类观察者。

以下列表仅包含协议改进，因其为主要改进，而一般改进数量过多，且即技术性。若果对更详细的信息感兴趣，请在版本列表中列出两者。

引入Chain ID

如前所述，审计的好处之一是引入Chain ID。虽然应该没有人在 TestNet 和 CoinNet 中使用相同的密钥对，但新的Chain ID 机制确保，即使存在，也无法将消息从一个网络复制到另一个网络。

Commons 支付间隔现在在 TestNet 上工作

我们的测试网出块间隔更短，验证者周期更短：出块速度比 CoinNet 快十倍，节点重新注册的频率要高出一百倍。在这种情况下，所有共识常量都被参数化，使我们的团队能够快速测试各种场景。 Commons 支付的初始实现在 TestNet 中出现了错误，此间隔未正确处理不同的块间隔，但已修复。

区块签名方案的变更

块签名方案被设计为可添加的：使用预映像方案，节点可以执行 Schnorr 签名，而无需此技术通常所需的设置。但是，发现了一个严重漏洞，攻击者窃取验证者的私钥。然后更改该方案以修补此漏洞，同时保留附加属性。目前已修补此漏洞，同时保留附加属性。但是，在相同高度的多个块上签名时，还发现验证器私钥不正确的问题。目前团队正在寻找替代方案解决。

块标题已更改为包含预映像

区块头之前包含两个组件，missing_validators 和 random_seed。前者预计几乎总是空的（因为它是被削减这个块的验证者列表），而后者是一个哈希，它是预映像的组合。然而，由于块本身依赖于其签名方案的预映像，这给验证者带来了一些问题，需要分别请求两个数据。

块标题已更改为包含预映像，并从中导出缺少的验证器及其随机seed。预映像仍可由验证器在内部压缩，因为只需保留注册的最终预映像（有时小于预映像），即可重新构建整个列表。

时间偏移(Time offset)已消除

当块的外部化时间固定在共识参数中时，节点基于本地时间 (误差范围 )，导出需要到达哪个高度。创世时间戳是共识参数的另一部分。由于外部化进程的多次改进，以前块标题中的 time_offset 已被删除，以解决外部化延迟。

解决已改善的区块冲突之方案

当出现竞争块和/或提名时，节点（和验证者）应该更喜欢那些有更多注册的节点，因为网络越大，安全性就越高。已把此概念引入在共识协议中。

冻结交易被重组为包括明确的手续费

原先, 被大幅削减的冻结交易是隐含进行的，此成为在钱包中成为问题。新的实现使slashing更加明确，同时使客户端更加清晰。

提名人数现受限制

提名大小现在有一个上限，这意味着块大小现在也受到隐式限制。

现需使用目标块高度对注册进行签名

当某个节点决定注册时，他们正在闲聊包含一些关键信息的结构。但是，此注册可能会因此而被延迟，并且未能包含在适当的高度，从而导致节点侧的调整问题。更糟糕的是，在某些情况下，敌对对等点可能会在罕见的情况下再次使用注册来尝试注册节点，所以，如果不在线注意，节点可能会被大幅削减。注册基于块高度进行签名。也就是说，这些注册仅适用于特定目标高度。

CoinNet 测试版发布计划

我们计划在 CoinNet 正式上线前, 于 2 月 16 日向外部自愿人士发布测试版本。当测试版本发布时，任何人都可以以验证者参与当中并观看网络运作的方式。我们开发的钱包和区块浏览器亦已链接到CoinNet 测试版，方便大家查看。

我们还计划在发布 CoinNet 测试版的同时举办活动。作为验证者参与或在测试版本验证过程中发现并报告错误的人士, 将通过抽奖能获得奖励。 CoinNet测试版公开活动详情将另行通知，敬请关注。

Please join our communication channels as follows!

Website(Kor/Eng/Chn): https://bosagora.io

Medium: https://medium.com/bosagora

Twitter: https://twitter.com/BOSAGORA1

Instagram https://instagram.com/bosagora_official

Youtube: http://bit.ly/2YFpd5r

Telegram (Official Announcement): https://t.me/boa_announcement

Telegram (Korean): https://t.me/bosagora_korea

Telegram (English): https://t.me/bosagora_eng