그래핀 2.0

스팀잇이라는 프론트엔드 웹사이트의 근간이 되는 백엔드, 스팀(기트허브 링크).
스팀, 비트셰어, Golos, 피어플레이, 뮤즈 등등의 근간이 되는 그래핀(기트허브 링크).
그래핀을 개선하기 위한 작업이 지금 진행중입니다.
3주전에 공식계정으로 올라온 글입니다.
https://steemit.com/steem/@steemitblog/steem-developer-update-graphene-2-0

그래핀은 댄더맨의 주장에 따르면 다른 블록체인 기술들보다 최소 2~3년은 앞서있다고 하던데,
이 작업을 마치고 나면 얼마나 더 앞서려는지...
참고로 5분 먼저가려다 50년 먼저간다는 말이 있죠. 별상관이 없는 얘기긴 합니다만.

그래핀 1.0은 2015년 6월에 비트셰어 2.0과 함께 나온 기술로,
LMAX라는 곳의 기술적 방법론에 따라 메모리에서 많은 연산을 처리하는 등 지갑노드의 퍼포먼스를 높여서
DPOS 증인서버 성능이 이상적으로 받쳐준다면 이론적으로 1초에 10만건의 트랜잭션을 처리할 수 있는 기술이라고 합니다.
https://bitshares.org/blog/2015/06/08/announcing-bitshares-2.0/
https://bitshares.org/technology/industrial-performance-and-scalability/

근데 스팀의 앞으로의 발전을 위해서 그런건지 몰라도
그래핀 기술을 더욱 개선해야할 필요가 있는가 봅니다.
노드들 간의 의사합의를 도출하기 위한 상태정보가 블럭체인 파일형태로 존재하지만 이것을 모두 메모리에 맵핑시키겠다고 합니다. 이렇게 하면 단점은 풀노드를 돌리기 위한 메모리가 더 많이 필요하게 되지만 장점은

• 노드를 켜거나 끌 때 속도가 빨라짐.
• 데이터베이스에 병렬적으로 동시에 접근 가능.
• 풀노드 프로세스가 예기치못한 상황에서도 죽지 않을 수 있는 안정성 강화.
• 데이터베이스에 잘못된 값이 들어가 오염될 확률 낮춤
• 모든 블럭체인 상태를 즉시 스냅샷 찍는게 가능해짐.
• 같은 메모리 용량으로 더 많은 RPC 요청을 처리 가능.

그래핀 1.0 에서는 모든 블럭체인 상태정보를 메모리에 넣고 Boost C++라이브러리의 멀티 인덱스 컨테이너 STL을 사용해서 접근할 수 있게 만들었습니다. 이런 방식은 기존의 블럭체인들에서 사용되는 조그만 사이즈(계정 잔고 정도의 정보를 주로 담는)의 블록체인에서는 적절했으나,
스팀의 경우 상태정보의 용량이 매우 큽니다.(아티클, 피드목록, 추천 등의 데이터) 그리고 스팀은 이 블럭체인 상태에 대한 쿼리가 아주 자주 일어납니다.(예를들어 스팀잇닷컴)

스팀은 현재 초당 트랜잭션이 발생하는 횟수가 비트코인에 이어 2위 입니다.
컨센서스 상태의 양이 늘어나는 속도는 현존 블럭체인중 최고로 빠릅니다.
스팀잇닷컴의 백엔드 풀노드를 돌리는데 필요한 메모리 양은 14GB 정도 입니다.(원본 출처의 글이 쓰여진 3주전 기준) 이것은 늘어나고 있습니다. 뭔가 새로운 기능을 추가할 때마다, 필요한 메모리 양도 늘어납니다.

새로운 노드를 켜면, 몇 기가바이트의 데이터를 인덱싱 시키는데 문제가 없으면 몇십초정도 걸립니다.
문제가 있다면 블럭체인의 상태를 트랜잭션 히스토리로부터 생성해내야 되기 때문에 가장 빠른 머신으로도 5분정도 걸립니다.

풀노드를 셧다운 시킬 때, 모든 데이터를 디스크에 저장해야 합니다. 역시 수십초가량 걸립니다. 뭔가 문제발생하면 다음번에 노드를 다시 켤 때 5분가량의 블록체인 리플레이 과정을 거치게 되겠죠.

그래핀 1.0 에서는 다른 블럭체인과 마찬가지로 싱글스레드 방식을 사용합니다. 멀티스레드를 동기화 시키는데 발생하는 오버헤드를 방지하기 위해서 인데요
보통의 블럭체인에서는 이렇게 해도 되지만 스팀은 보통의 블럭체인이 아니라 많은 리퀘스트를 처리해야 하는 블럭체인이기 때문에 ... 데이터베이스를 읽고 쓰는 프록시 커넥션이 한 노드에 150개 정도가 성능저하 없이는 한계치이고, 노드를 늘리고 로드밸런싱을 하면 또 14GB 이상의 메모리를 먹는 서버를 돌려야 하게 됩니다.

어려운 내용 좀 생략하고 결론부로 넘어가서

There will be an extensive period of testing where old and new versions of Steem will be running side by side to ensure we do not accidentally introduce a consensus changing unexpected hard-fork.
After the migration to Graphene 2.0 is complete, we will return our attention to Curation Guilds.
새버전와 구버전의 스팀 블록체인이 잘 돌아가며 의사결정을 과정에 체인 분리가 일어나지 않도록 하기 위해 많은 테스팅을 해야 할것이며,
이 작업이 되고나면 "큐레이션 길드" 작업을 하겠다.

그리고 댓글중에 능력자 xeroc 의 말에 따르면

there shouldnt be much of a problem .. except more work for devs
아마 별 문제는 없을것이며 개발자들 할일 많겠네.