Functionality Implementations

Implement support for non-interactive threshold signatures (linear complexity, not MuSig) #1428 (Basic Script Execution Engine, Feature)

As of today, there are only a few (maybe just one?) non-interactive Schnorr threshold signature schemes that exist. One of them is MuSig. Since implementing support for MuSig is non-trivial it’s not a bad idea to implement a stop-gap measure by adding support for multi-sigs in the same way as Bitcoin’s CHECK_MULTI_SIG.

Design & implement slashing rules for missing pre-images #1076 (Slashing Protocol, Feature)

Currently, we are building rules based on the availability of pre-images: signature scheme and quorum balancing. We also have a timer in place to ensure our pre-images are available long before we need them. Now we need to add a way to detect and log whenever pre-images are missing, decide on a policy of what to do with it, and implement it.

Detection

The first step is to detect whenever we are missing a pre-image. This will allow us to make sure we have everything properly implemented at the moment. Once this is the case, we can move on to writing a test case. That test case should have at least one node in the network doing the following:

• (A) Never send any pre-image after its initial enrollment;
• (B) Only send one pre-image after enrolling then no more;
• © Send pre-image for half of its cycle (potentially in one burst) then stop sending pre-image;
• (D) Send pre-image for half its cycle, stop it for a quarter of the cycle, resume until the end; Those 4 situations should be tested independently, so not during the same cycle, and not using the same utxo key / public key.

This will allow us to see how the network currently behaves when faced with those situations, and correct any remaining issue.

Policy Decision

Once we have that basis in place, we will need to come up with the slashing policy for missing pre-images. As discussed in the previous meetings, missing pre-images is one of the gravest mistakes a validator can commit, short of outright hostile actions (such as signing two blocks for the same height).

The following was discussed before any implementation took place:

• Gradual punishment for validators missing to relay their pre-image, so that they still have an incentive to come back and propagate them if they miss a deadline. The more pre-images, the safer the randomness function.
• Applying a loss-of-income penalty to the quorum: this gives a strong incentive to the quorum to keep and propagate pre-images for nodes in their quorum, ensuring that they will not simply ignore them to maximize the penalty of a validator;

Expose a basic API #15 (Faucet, Feature)

The faucet should expose a basic API so it can be called from a frontend service (website) to make Transactions. Additionally, some functionality could be useful for debugging or management.

The basic API is comprised of:

• GET /utxos => Return an array of all UTXOs known;
• POST /send?recv=KEY&amount=1234: Send amount BOA to KEY, using owned UTXOs;

Schnorr multi-signature of blocks #1319 (Block Creation, Feature)

Node operators now have the ability to perform Schnorr multi-signatures for the block signature. In order for this event to take place more than half the validators must sign a block that has reached consensus before it will be externalized.

Validators “gossip” their block signatures after the block is externalized, which means that even after consensus is reached, and the block is externalized, more validators can add their signature to the block.

Ongoing Development

• Decouple TxBuilder from well-known KeyPair #1348
• Implement transaction fee collection #1435
• Agora crashes on too large input #1278
• Implement indirect payment channels via HTLCs #1419
• libexecinfo (used on Alpine Linux) is buggy #1407
• Flash layer research & development #1266 (Ongoing)

Functionality Implementations

#1428 비상호적인 임계 서명 지원 구현(선형 복잡도, Musig 아님), 기본 스크립트 실행 엔진, 기능

현존하는 비상호적인 Schnorr 임계 서명 체계는 많지 않습니다 (아마도 하나 정도). 그중 하나가 MuSig입니다. MuSig에 대한 지원을 구현하는 것은 간단하지 않기 때문에 비트 코인의 CHECK_MULTI_SIG와 같은 방식으로 다중 시그에 대한 지원을 추가하는 임시 조치를 구현하는 것은 좋은 방법입니다.

#1076 누락된 프리이미지를 위한 슬래싱 룰 설계 및 구현 (슬래싱 프로토콜, 기능)

현재 개발팀은 사전 이미지의 가용성 (서명 체계 및 쿼럼 밸런싱)을 위한 기반 규칙을 구축하는 중입니다. 또한 프리 이미지가 필요해지기 훨씬 전부터 프리 이미지를 사용할 수 있도록 타이머를 준비해 두었습니다. 이제 프리이미지가 누락될 때마다 감지 및 기록하는 방법을 추가하고 이를 처리할 정책을 결정하고 구현해야 합니다.

감지

첫 단계는 사전 이미지가 누락될 때마다 감지하는 것입니다. 이를 통해 현재 모든 것이 제대로 구현되었는지 확인할 수 있습니다. 이 경우 테스트 케이스 작성으로 넘어갈 수 있습니다. 해당 테스트 케이스는 다음을 수행하는 네트워크에 하나 이상의 노드가 필요합니다.

(A) 최초 등록 후에는 사전 이미지를 보내지 말 것.
(B) 등록 후 하나의 사전 이미지 만 보내고 더 이상 보내지 않음.
(C) 주기의 절반 동안 (잠재적으로 한 번의 버스트에서) 사전 이미지를 보낸 다음 사전 이미지 전송을 중지함.
(D) 주기의 절반 동안 사전 이미지를 보내고, 주기의 1/4 동안 중지하고, 끝까지 다시 시작함. 이 4가지 상황은 독립적으로 테스트해야 하며, 동일한 주기일 필요가 없고, 동일한 utxo 키 / 공개 키를 사용하지 않아야 함.

이를 통해 네트워크가 해당 상황에 맞닥뜨렸을 때 어떻게 반응하고 남은 이슈들을 어떻게 처리하는지 확인할 수 있습니다.

정책 결정

기반이 마련되면 사전 이미지 누락에 대한 슬래싱 정책을 마련해야 합니다. 이전 회의에서 논의한 바와 같이, 누락된 사전 이미지는 검증자가 범할 수 있는 가장 심각한 실수 중 하나이나, 노골적인 적대 행위 (예 : 같은 높이의 두 블록에 서명)는 없습니다.

정책 구현 전, 다음 사항이 논의되었습니다.

프리이미지를 전달하지 못한 검증자에 대한 점진적 처벌을 통해, 마감일을 놓친 경우 다시 돌아와 전파하도록 합니다. 프리이미지가 많을수록 무작위성 기능이 더 안전합니다.

쿼럼에 소득 손실 페널티 적용 : 검증 자의 패널티를 최대화하여, 쿼럼이 쿼럼 내 노드에 대한 프리이미지 유지와 전파를 무시하지 않고 전파하도록 하는 강력한 동기를 제공합니다.

#15 기본 API 노출(Faucet, 기능)

Faucet는 트랜잭션을 만들기 위해 프런트엔드 서비스 (웹 사이트)에서 호출할 수 있도록 기본 API를 노출해야 합니다. 또한 일부 기능은 디버깅 또는 관리에 유용할 수 있습니다.

기본 API는 다음으로 구성됩니다.

• GET /utxos => 알려진 모든 UTXO들의 집합체의 반환
• POST /send?recv=KEY&amount=1234: 보유한 UTXOs를 이용해 BOA를 KEY로 보낸다;

#1319 블록들의 쉬노르 다중 서명 (블록 생성, 기능)

이제 노드 운영자는 블록 서명에 대해 Schnorr 다중 서명을 수행할 수 있습니다. 검증자의 절반 이상이 블록이 외부화되기 전에 합의에 도달 한 블록에 서명해야 합니다.

검증자는 블록이 외부화된 후 블록 서명을 “가십”합니다. 즉, 합의에 도달하고 블록이 외부화된 후에도 더 많은 검증자가 블록에 서명을 추가할 수 있습니다.

Ongoing Development

• #1348 잘 알려진 키페어로부터의 디커플 Tx빌더
• #1435 트랜잭션 수수료 징수
• #1278 너무 큰 입력에 Agora 충돌
• #1419 HTLCs를 통한 간접 지불 채널 구현
• #1407 libexecinfo(알파인 리눅스에서 사용된)는 버그투성이다
• #1266 플래시 레이어 리서치 및 개발(진행 중)

Please join our communication channels as follows!

Website(Kor): https://bosagora.io/ko
Website(Eng): https://bosagora.io
Telegram(Kor): https://t.me/bpf_korea
Telegram(Eng): https://t.me/bpf_eng
BOSAGORA Official Announcement: https://t.me/boa_announcement
Medium: medium.com/bosagora
Twitter: https://twitter.com/BOSAGORA1
Reddit: https://www.reddit.com/r/BOSAGORA_BOA/
Facebook: https://www.facebook.com/BOSAGORA/
Linkedin: https://www.linkedin.com/company/bpf-korea/
Youtube: http://bit.ly/2YFpd5r
Github: https://github.com/bpfkorea

BOSAGORA TEAM