에스프레소, 같은 뷰서 두 차례 투표로 블록 확정

에스프레소(Espresso)가 핫샷(HotShot)의 블록 최종 확정 절차를 바꿔 두 차례 투표를 같은 뷰 안에서 마치도록 했다. 기존에는 정족수 표를 이미 얻은 블록도 뒤이은 리더의 제안과 투표가 이어져야 확정됐다.

에스프레소 개발사 에스프레소 시스템즈(Espresso Systems)는 20일 공개한 기술 설명에서 지난 9월 메인넷 업그레이드에 적용한 합의 방식의 작동 원리를 밝혔다. 본지는 앞서 9월 메인넷 업그레이드 뒤 거래 최종 확인 시간이 1초 이내로 줄었다고 보도했다. 이번 설명은 그 속도를 뒷받침한 합의 규칙을 다룬다.

뷰는 리더가 블록을 제안하고 검증자들이 투표하는 합의 단위다. 정족수는 합의에 필요한 최소 투표 수를 뜻한다. 기존 핫샷은 한 뷰에서 정족수 표를 모아도 블록을 바로 확정하지 않는 연쇄 제출 방식을 사용했다.

한 뷰의 투표 증명서를 다음 뷰의 제안에 담고, 그다음 뷰의 증명서도 이어서 전달해야 앞선 블록이 확정됐다. 각 뷰에서 제안과 투표를 한 차례씩 진행하는 구조였다.

블록의 최종 확정은 뒤따르는 뷰들이 정상적으로 진행되는지에 달렸다. 후속 리더가 늦거나 오프라인이 되면, 이미 정족수 표를 모은 블록도 확정을 기다릴 수 있었다.

새 방식에서는 리더가 블록을 삭제 부호화로 여러 조각으로 나눠 검증자에게 보낸다. 삭제 부호화는 조각 일부를 모아 원래 데이터를 복원하는 방식이다.

자신의 조각을 받은 검증자는 첫 투표를 다른 모든 검증자에게 전파한다. 첫 투표가 정족수를 채우면 어느 노드든 첫 증명서를 만들고 해당 블록을 잠근 뒤 두 번째 투표를 보낸다.

두 번째 투표도 정족수를 채우면 노드가 두 번째 증명서를 만들고 블록을 최종 확정한다. 두 차례 투표가 모두 같은 뷰에서 끝나므로 이후 리더의 상태가 해당 블록의 확정을 좌우하지 않는다.

투표를 전달하는 방식도 달라졌다. 기존에는 검증자들이 표를 한 리더에게 보내고 리더가 증명서를 만들었지만, 새 방식에서는 검증자들이 서로 표를 주고받는다. 정족수 표를 확인한 노드라면 누구든 증명서를 만들 수 있다.

메시지 복잡도는 검증자 수를 n이라고 할 때 기존 O(n)에서 O(n²)으로 늘어난다. 대신 투표 집계가 리더 한 명의 응답에 묶이지 않아 단일 노드의 지연이나 장애로 생기는 정체를 줄일 수 있다.

에스프레소 시스템즈는 검증자가 약 100명인 현재 규모에서는 투표 메시지가 작아 부담을 감당할 수 있다고 설명했다. 검증자 수가 10배 이상 늘면 위원회 추출, 서명 집계, 단계별 투표 전달 같은 보완책이 필요할 수 있다고 덧붙였다.

투표를 서로 주고받고 노드마다 증명서를 만들 수 있게 되면서 기존의 뷰 동기화 하위 절차도 필요하지 않게 됐다. 일부 표를 놓친 노드도 다른 노드가 만든 증명서를 받으면 결정을 내릴 수 있고, 리더가 오프라인이거나 악의적으로 행동하는 경우에는 타임아웃 증명서를 이용한다.

데이터 가용성 확인도 합의 투표에 포함됐다. 기존에는 합의 투표 전에 별도 데이터 가용성 위원회가 블록 데이터를 받아 투표하고 증명서를 만들었다.

새 방식에서는 리더가 지분 비중에 따라 검증자들에게 블록 조각을 배정한다. 조각을 받은 검증자만 첫 투표를 할 수 있으며, 지분의 3분의 2에 해당하는 검증자들이 투표하면 블록을 복원할 만큼의 조각이 존재한다는 근거가 된다. 이에 따라 별도 데이터 가용성 위원회와 그 투표 절차를 없앴다.

CometBFT도 블록을 확정할 때 두 종류의 투표를 사용한다. 다만 CometBFT는 전체 블록을 투표 대상으로 삼는 반면, 새 핫샷은 삭제 부호화한 조각을 나눠 보내고 투표를 데이터 가용성 증명에도 활용한다.

에스프레소 시스템즈는 악의적인 검증자의 지분이 3분의 1 미만일 때 서로 충돌하는 두 블록이 동시에 최종 확정되지 않는 안전성은 유지된다고 밝혔다. 에스프레소의 최종 확정은 롤업이 전달한 데이터와 거래 순서를 확정하는 절차로, 롤업의 거래 실행이나 이더리움(ETH) 같은 상위 체인에서의 정산까지 끝났다는 뜻은 아니다.