Reading:
BOSAGORA 8월 월간 리포트: BOSAGORA 쿼럼 밸런싱 개발 완료 외
Image

BOSAGORA 8월 월간 리포트: BOSAGORA 쿼럼 밸런싱 개발 완료 외

by Rooney
2020-09-14

BOSAGORA 8월 월간 리포트

 

개발

Image for post

8월, BOSAGORA 개발팀은 BOSAGORA 합의 알고리즘에서 가장 중요한 쿼럼 밸런싱 MVP를 성공적으로 개발 완료했습니다. 쿼럼 밸런싱의 개발 덕분에 쿼럼에서 검증자를 신뢰하는 방식이 개별적인 검증자 모두가 아닌 다양한 방식으로 묶인 작은 단위의 검증자 그룹을 신뢰하도록 하여, 세계 최초의 탈중앙화 플랫폼을 만드는데 한 발자국 더 다가가게 되었습니다.

쿼럼 밸런싱 개발 완료 내용 확인하기
https://bit.ly/2Zj80Sl

또한, 개발팀은 제3자가 BOSAGORA 플랫폼에 서비스를 구축할 수 있도록 Stoa SDK/API를 개발하는 작업을 계속 진행해왔습니다. 아래에 현재 진행 중인 지난달의 개발 활동들을 요약했습니다.

8월의 핵심 개발사항:
월별 활동:

지난달 저희는 52개의 Agora 관련한 풀리퀘스트와 30개의 활성 이슈가 있었습니다. 그 중:

  • 9개의 풀리퀘스트가 열렸고,
  • 52개의 풀리퀘스트가 통합되었고,
  • 5개의 새로운 이슈가 있었고,
  • 25개의 이슈가 닫혔습니다.

개발된 기능:

#1062 “무효한 프리이미지 데이터” 메시지가 연결되지 않은 노드에서 발생하는 이슈

이 기능은 8월 초 구철이 개발했습니다. 아래 메시지가 비어있는 혹은 연결되지 않은 검증자들에서 보인다면 이는 프리이미지 전파나 제네시스 블록의 버그를 의미합니다. 이는 일종의 버그로 수정 후 해결했습니다.

$ dub build

$ cd test/system/node/2/

$ ../../../../build/agora

[…]

[main(ZbnT) INF] Listening for requests on http://0.0.0.0:2826/

Task terminated with uncaught exception: Request failure to http://node-6:6826 after 5 attempts

Task terminated with uncaught exception: Request failure to http://node-7:7826 after 5 attempts

Task terminated with uncaught exception: Request failure to http://node-4:4826 after 5 attempts

Task terminated with uncaught exception: Request failure to http://node-5:5826 after 5 attempts

Task terminated with uncaught exception: Request failure to http://node-3:3826 after 5 attempts

2020–07–27 09:15:36,758 Info [agora.consensus.ValidatorSet] — Invalid pre-image data: The pre-image has a invalid hash value. Pre-image: { enroll_key: 0xb20da9cfbda971f3f573f55eabcd677feaf12f7948e8994a97cdf9e570799b71631e87bb9ebce0d6a402275adfb6e365fdb72139c18559a10df0e5fe4bae08eb, hash: 0x148006017980424589fc1a7f360f815ef1bcce71a3bd0b581f7a126a57449cb058bba5eca3642cac3e93c15ebd2f2d54d206e6ee3c7fc06b8a59e597d5e02840, distance: 11 }

더 많은 정보는 아래 깃허브 링크를 참고하세요:
https://github.com/bpfkorea/agora/issues/1062

#55 JSON 데이터 검증을 위해 JSON-Schema 사용

Image for post

이 기능은 8월 초 마이클이 개발했습니다. 기존에는 JSON 데이터 속성들만이 검증되어, 검증 관련 통일된 방식이 필요했습니다. 개발 이후, 이후 JSON 데이터를 검증할 때, 표준 방식으로 검증합니다.

아래는 완료 정의된 내용입니다:

  • JSON-Schema를 사용하여 자동적으로 인터페이스를 생성합니다.
  • 인터페이스를 사용하여 JSON 데이터를 검증할 기능을 생성합니다.
  • 모든 소스에 새로운 검증 방식을 적용합니다.

더 많은 정보는 아래 깃허브 링크를 참고하세요:
https://github.com/bpfkorea/stoa/issues/55

#22 최신 PR(코드 병합 요청)이 통합될 때 자동적으로 생성되는 SDK 문서를 가진 웹페이지 추가하기

이 기능은 8월 초 마이클과 헨리가 개발했습니다. 이 기능 덕분에 개발팀의 문서 생성 및 접근, 관리가 매우 편리해졌습니다.

참고 사이트:
https://github.com/TypeStrong/typedoc
https://typedoc.org/guides/installation/

자동적으로 생성된 문서 샘플:
https://typedoc.org/api/

더 많은 정보는 아래 깃허브 링크를 참고하세요:
https://github.com/bpfkorea/boa-sdk-ts/issues/22

#51 블록 저장 처리에 DB 트랜잭션 적용

이 기능은 8월 초 헨리가 개발했습니다. 이는 블록/트랜잭션이나 검증자 등록 저장 시 오류가 발생할 때 복원하는

역할을 합니다. 예를 들어, 블록 정보 저장 시, 정보에 블록 헤더 데이터만 있는 등 실제 원장 데이터와 일치하지 않을 때

롤백을 수행하여 테이블에서 이를 복원합니다.

더 많은 정보는 아래 깃허브 링크를 참고하세요:
https://github.com/bpfkorea/stoa/issues/51

#1069 쿼럼들은 정기적으로 리셔플(재배정) 되어야 함

Image for post

이 기능은 8월 말 드레이가 개발했습니다. 현재 쿼럼 세트는 검증자 세트에 변화가 있을 때, 신규 등록을 하거나 등록을 만료시킵니다. 셔플링은 N이 합의 파라미터일 때, 매 N블럭마다 쿼럼을 셔플 하는 등 자주 발생해야 합니다.

이를 위해 일부 지지 코드가 필요하고, 해당 유닛 테스트는 아래 내용을 포함합니다:

  • 검증 사이클을 20으로 설정
  • 제네시스 생성
  • 19개 블록 생성
  • 노드 시작

노드들은 제네시스 블록 등록에 커밋먼트를 제외하고, 시작 시점에 프리 이미지를 갖고 있지 않습니다. 만약 “주기적 셔플”의 N파라미터를 10으로 설정하면, 부트업에서 노드들은 블록 높이 0 그리고 블록 높이 10의 쿼럼을 생성할 것입니다. 높이 10의 프리 이미지들은 후에 테스트를 진행할 예정입니다.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/agora/issues/1069

#854 검증자는 만료된/연결이 끊긴 검증자에 연결 시도 중 차단될 수 있음(테스트 케이스)

이 기능은 8월 말 제이가 개발했습니다.

아래 시나리오를 참고하십시오:

  • 검증자는 빈 블록체인으로 시작함.
  • 네트워크의 실제 최신 블록 높이는 100_800임.
  • 검증자는 네트워크를 찾기 위해 DNS 시드를 사용함.
  • 검증자는 제네시스 블록의 등록에 설정된 것처럼 퍼블릭 키를 가진 검증자를 찾을 때까지 네트워크를 검색함.

제네시스 블록에 등록된 검증자들은 만료될 수 있기에 유의해야 합니다.

변경될 부분:

  • 캐치업 단계가 네트워크 발견 단계와 동시에 이루어져야 함.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/agora/issues/854

#855 기 등록된 검증자가 즉시 검증을 시작할 수 있도록 함

이 기능은 8월 말 제이가 개발했습니다. 검증자는 기 등록되었을 때 부트업이 가능합니다. (만약 노드가 다른 노드를 위한 백업 노드인 경우).

아래 내용을 테스트할 것입니다:

  • 소수의 노드들로 네트워크를 시작함;
  • 깨끗하게 지워지고 작동이 중단된 한 등록 노드를 가짐;
  • 적어도 2개 블록들을 기다림;
  • 노드를 재시작하고, 캐치업했다는 것을 검증하고, 다시 검증을 시작함;

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/agora/issues/855

#304 SEC1 v2(v2.3)에 따라 슈노르 서명 인코딩을 구현함

링크된 논문의 섹션 v2.3을 참고하세요: https://www.secg.org/sec1-v2.pdf

이 기능은 8월 말 크리스가 개발했습니다. 해당 기능은 Libsodium의 내부 상황에 의존했던 관계로, 대중에 공개하기 전 개발을 완료했습니다.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/agora/issues/304

#59 실행 중에 발생하는 로그들을 관리할 능력이 필요

이 기능은 8월 말 헨리가 개발했습니다. 해당 기능은 프로세스가 작동하는 중에 예외사항이 발생하면 로그 외에 저장되지 않은 모든 데이터를 복구할 수 있도록 합니다.

간단한 필요사항:

  • 로그 유형을 명시할 수 있는 능력이 있어야 함.
  • 로그 파일의 최대 크기 설정이 가능해야 함.
  • 로그의 산출물은 파일과 콘솔에 설정될 수 있어야 함.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/stoa/issues/59

#825 “base docker build” 이미지를 제공함

이 기능은 8월 말 다니엘이 개발했습니다. 다커 이미지를 처음부터 제작하려면 업그레이드 된 GCC를 포함해 45개 패키지를 설치해야 하는 등 시간이 많이 소요되었는데, 엣지를 쓰다보니 이런 현상이 자주 일어났습니다. 따라서, 이를 극복하기 위해 해당 기능을 개발했습니다.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/agora/issues/825

#1024 해시맵 비검증 이슈를 적절하게 수정함

이 PR은 우회로를 구현함: #1023

이 기능은 8월 말 다니엘이 개발했습니다. 모든 고객 리스트에 배열을 사용하는 것은, 한계 설정이 가능하고, 사용되지 않은 클라이언트를 제거할 수 있어 편리하지만, 배열이 너무 커질 수 있기 때문에 우회로를 구현했습니다.

아래는 해당 이슈를 보여주는 테스트케이스입니다:

import std.stdio;

import agora.utils.Test;

import agora.common.crypto.Key;

void test () @safe

{

int[PublicKey] map;

map[WK.Keys[0].address] = 10;

map[WK.Keys[1].address] = 20;

map[WK.Keys[2].address] = 30;

map[WK.Keys[3].address] = 40;

map[WK.Keys[4].address] = 50;

size_t count;

foreach (ref key, ref value; map)

{

writeln(“In map (before blowItUp) Key: “, key, “, value: “, value);

++count;

if (count == 3)

blowItUp(map);

writeln(“In map (after blowItUp) Key: “, key, “, value: “, value);

}

}

void blowItUp (ref int[PublicKey] map) @safe

{

for (int v = 6; v < 512; ++v)

{

map[WK.Keys[v].address] = v * 10;

writeln(“Adding: Key: “, WK.Keys[v].address, “, value: “, v * 10);

}

}

unittest

{

test();

}

Notice the corruption here in the printouts:

n map (after blowItUp) Key: GDC22CFFKB4ZNRZUP6EMRIGVZSQEPSNH2CBMWLU5GLGKE36M3KX5YD36, value: 30

In map (before blowItUp) Key: GAEAAAAAAAAAAAGPHEVAWAIAAAAAAAAAAAAAAAAAIAA5SCQBAAAABOWV, value: 10

In map (after blowItUp) Key: GAEAAAAAAAAAAAGPHEVAWAIAAAAAAAAAAAAAAAAAIAA5SCQBAAAABOWV, value: 10

In map (before blowItUp) Key: GABQAAAAAAAAAAFKHEVAWAIAAAAAAAAAAAAAAAAAUD5NQCQBAAAAB2H7, value: 10

In map (after blowItUp) Key: GABQAAAAAAAAAAFKHEVAWAIAAAAAAAAAAAAAAAAAUD5NQCQBAAAAB2H7, value: 10

In map (before blowItUp) Key: GAFAAAAAAAAAAAGEHEVAWAIAAAAAAAAAAAAAAAAAUD65QCQBAAAAAYG6, value: 8

In map (after blowItUp) Key: GAFAAAAAAAAAAAGEHEVAWAIAAAAAAAAAAAAAAAAAUD65QCQBAAAAAYG6, value: 8

In map (before blowItUp) Key: GAFAAAAAAAAAAAGYHEVAWAIAAAAAAAAAAAAAAAAA6AA5SCQBAAAAAMIZ, value: 1919903585

In map (after blowItUp) Key: GAFAAAAAAAAAAAGYHEVAWAIAAAAAAAAAAAAAAAAA6AA5SCQBAAAAAMIZ, value: 1919903585

처음에는 _aaRehash를 호출하는 것으로 여겼지만, 이는 사실 .rehash() call(_aaRehash는 자동으로 호출되지 않습니다)을 위한 사용자 대면 API입니다. 여기 나온 기능 중 하나에 내부 호출이 있습니다.

https://github.com/dlang/druntime/blob/master/src/rt/aaA.d#L126-L155

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/agora/issues/1024

#1122 Sqlite 데이터베이스의 종료 함수는 ManagedDatabase를 사용할 때에도 여전히 GC 쓰레드에서 호출됨

이 기능은 8월 말 다니엘이 개발했습니다. 기존 구현된 ManagedDatabase에는 최소 2개의 버그가 있었고, 이는 리눅스 배포(Debian과 Ubuntu) 최신 안정 버전에서의 유닛 테스트를 방해했습니다. 따라서, 이를 해결하기 위해 해당 기능 개발을 완료했습니다.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/agora/issues/1122

#69 LedgerStorage 방식에 Promise를 사용하여 개선함

이 기능은 8월 말 Michael이 개발했습니다. Async와 await를 사용하면 네스트 콜백을 사용하지 않고 반복되는 문구를 쉽게 쓸 수 있습니다. 이를 활용하려면, 리턴 기능으로 Promise<return type>를 정의해야 합니다. 하지만 LedgerStorage 방식은 조금 다릅니다. 이는 Promise<return type>를 돌려주는 기능으로 변경되었습니다. 또한 이를 사용하는데 다양한 방안을 제공할 것입니다.

async/ await/ promis 사용 사례

async function putAllBlockData (ledger_storage: LedgerStorage,

callback: (err: Error | null) => void)

{

// Use Promise to record block data synchronously.

let save = (storage: LedgerStorage, block: any) =>

{

return new Promise<boolean>((resolve, reject) => {

storage.putBlocks(block, ()=>{resolve(true);}, (error)=>{reject(error);});

});

};

for (let elem of sample_data)

{

try

{

await save(ledger_storage, elem);

}

catch (error)

{

callback(error);

return;

}

}

callback(null);

}

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/stoa/issues/69

#79 ‘Hash’ 클래스에서 해싱 기능을 분리함

이 기능은 8월 말 마이클이 개발했습니다. 이 클래스는 해시 결과값의 바이너리 데이터를 갖는 것을 단순화합니다.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/stoa/issues/79

#45 Agora에서 사라진 블록들을 요청하고 복구할 수 있는 능력을 구현함

이 기능은 8월 말 마이클이 개발했습니다. Stoa가 블록을 정상적으로 다루게 하기 위해서, 블록들은 그들의 높이 순서에 따라 정확하게 입력되어야 합니다.

현재 받은 블록의 높이와 이전에 처리된 블록의 높이 차이는 반드시 1이 되어야 합니다. 만약, 이 값이 2라면, 한 블록이 사라졌다고 추론할 수 있습니다. 그리고 블록이 사라지게 되면 자동적으로 복구할 수 있는 능력을 추가하기 위해 해당 이슈를 생성했습니다.

이를 해결하기 우해 아래 두 가지 절차에 따라 진행했습니다:
1. Agora 블록에 포함된 모든 객체들의 시리얼라이제이션과 디시리얼라이제이션 기능을 구현.

2. 블록 데이터를 복구하는데 필요한 실질적인 기능들을 구현.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/stoa/issues/45

#52 /preimage_received endpoint를 구현함

구현할 API:
POST/preimage_received

노드는 주기적으로 프리이미지를 푸시 합니다.
Stoa는 프리이미지를 받고 Stoa 데이터베이스에 이를 저장합니다.
프리이미지는 각 PreImageCycle의 cycle_length에 가까운 마지막 프리이미지만을 저장합니다.
이는 /getValidator와 /getValidators의 프리이미지 정보를 향상할 수 있습니다.

PreimageInfo의 JSON 유형

{

“enroll_key”:”0x000000000019d6689c085ae”,

“hash”:”0x4a5e1e4baab89f3a32518a88″,

“distance”:6

}

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/stoa/issues/52

#46 Stoa가 CORS 정책에 의해 차단

이 기능은 8월 말 헨리가 개발했습니다. 이를 통해 브라우저를 통해 Stoa에 접근 시, CORS 정책으로 인해 차단됩니다.

더 많은 정보는 아래 깃허브를 참고하세요:
https://github.com/bpfkorea/stoa/issues/46

진행 중인 검증자 개발:

  • gossiping을 위한 노드별 요청 큐 구현 #1149
  • 비밀키와 서명을 위한 시드 구현 #28
  • Homebrew LDC 버전을 v1.23.0으로 업그레이드 #39
  • 프리 이미지 노출 유닛테스트가 실제 프리 이미지 노출을 테스트하지 않는 문제 #1071
  • ‘makeChainedTransactions’ 제거 #1107
  • 업스트림 Vibe.d 이슈 조사: 누수 처리 #1136
  • /block_externalized 엔드 포인트가 일반에게 공개될 필요 없음 #76
  • 아고라의 블록 구조와 같이 데이터 타입을 재정의 #81
  • 데이터베이스에 현재 블록 헤더의 해시 값 추가 #84
  • 풀에 있는 트랜잭션 수에 기반해 블록은 생성하는 것으로부터 변경 진행 #1004
  • 노드 구성과 블록 저장 지속성이 확인되지 않음 #1006
  • Ledger 메소드들이 throw와 boolean 상태 코드를 혼용하여 반환하는 문제 #1083
  • 윈도우에서 유닛테스트가 수행되면 에러 코드를 반환하는 문제 #820
  • 리더 선출 루틴에 대한 개선 필요 #1079
  • 블록에 대한 Schnorr 기반 서명을 구현 #365
  • 아고라의 hashFull과 hashPart 기능을 구현 #83
  • 데이터베이스에 블록 데이터를 저장할 때, 저장 공간 절약 필요 #60
  • 캐시 디렉토리 상에 락(Lock)을 구현 #829
  • 혼란을 주는 깃허브 CI 오류 #882
  • 테스트를 더 효율적이고 신뢰할 수 있게 하도록 하기 위해 VirtualClock을 구현 #389
  • 특별한 경우에 segfault를 유발할 수 있는 Log.d에 대한 수정 #1128

마케팅

써머 겟어웨이 캠페인

Image for post

코로나 2차 대유행, 사회적 거리두기 강화, 원격 근무의 생활화 등 코로나로 인해 우리의 삶이 변했고, 이에 많은 사람들이 점점 지쳐가고 있습니다. 어느덧 여름이 다가왔고 사람들의 마음은 자유롭게 여행을 다니던 시절에 대한 향수로 더 심란해졌습니다.

하지만 여전히 여행을 다니는 건 힘든 상황이기에 BOSAGORA는 커뮤니티 멤버들끼리 ‘여행 가고 싶은 장소’를 공유하는 캠페인을 통해 많은 사람들이 과거의 추억을 회상하고, 서로 다양한 휴양지를 추천하며, 코로나 이후의 밝은 미래에 대해 그리는 시간을 가졌습니다.

‘더 나은 세상’을 위한 비전의 실현을 목표로 하는 BOSAGORA는 코로나 시대를 더욱 슬기롭게 극복하고, 더 건강한 삶을 누릴 수 있도록 다양한 커뮤니티 활동을 실시하겠습니다.

인도 커뮤니티 BOSAGORA 캠페인

Image for post

BOSAGORA는, 올 초, BOSAGORA 소개 유튜브 영상 콘텐츠를 제작한 글로벌 커뮤니티 중 하나인 인도 커뮤니티와 함께 BOSAGORA를 알리는 캠페인을 추가 진행했습니다.

미디엄 내 BOSAGORA 콘텐츠를 체험하고, 이를 리트윗으로 수많은 친구들에게 알려 BOSAGORA가 더 많이 노출되도록 설계하여 진행한 이번 캠페인을 통해, BOSAGORA의 콘텐츠의 조회 수 및 트위터 팔로우 및 RT(콘텐츠 공유)가 수백 건씩 늘며 커뮤니티에 활기를 불어넣었습니다.

UN SDG COVID 씨티즌 액션 캠페인

Image for post

BOSAGORA는 케어 프로젝트(Project Care)의 수상 이후에도 지속적으로 UN SDG의 다양한 활동에 귀를 기울이며 블록체인 프로젝트로서 SDG에 기여할 수 있는 방법을 고민하고 있습니다. 이에, UN SDG의 COVID 씨티즌 액션 캠페인에 서명하면서 코로나 극복과 인류의 번영을 위한 행동에 다시 한번 동참했습니다.

COVID 씨티즌 액션 캠페인은 UN에 촉구하는 4 가지 사항과 참여국 및 지원 단체에 바라는 단기 및 중, 장기적인 복구 단계 별 8가지의 요청 사항으로 구성되어 있습니다.

BOSAGORA가 추구하는 ‘더 나은 세상’은 단 한 번의 사건으로 만들어지지 않습니다. 저희는 세상과 사회에 대한 꾸준한 관심과 실천을 통해 진정으로 ‘더 나은 세상’에 기여하도록 하겠습니다.

캠페인 관련 자세한 내용은 아래 링크에서 확인하시기 바랍니다.
https://bit.ly/2QZ0JlR

8월 빗보이 콘텐츠

Image for post

비트보이의 8월 콘텐츠에서 비트보이는 BOSAGORA가 프로젝트 인에이블러로서 프로젝트들의 인큐베이터 역할을 하고 ‘Make a better world’를 추구하며, UN SDG를 실현하는 블록체인 프로젝트로 심도 있게 조명했습니다. 이와 관련하여 최근 Jia You 캠페인, 그리고 TypeScript SDK 개발 등 다양한 활동과 개발 내용도 소개했습니다.

비트보이 8월 콘텐츠 확인하기
https://bit.ly/3lbgsMx

테크 트렌드 9, 10화 발행

Image for post

테크 트렌드는 블록체인 업계의 기술 및 트렌드를 조망하는 BOSAGORA의 칼럼으로 8월에는 9, 10화가 발행되었습니다. 상세한 내용은 링크에서 확인하시기 바랍니다.

9화 BOSAGORA만의 블록체인
https://bit.ly/3byroiS

10화 암호화폐 산업의 부흥을 위한 민주주의의 도입
https://bit.ly/3jMx7EK


0 Comments

댓글 남기기

Related Stories

Arrow-up