v19 하드 포크 이슈 해결
v19 하드 포크의 주요 목표 중 하나는 기본 BLS 계획을 활성화하고, 다양한 온체인 및 p2p 메시지에서 이를 활용하기 시작하는 것이었습니다. 이와 같은 변화가 고안된 까닭은 IETF 표준에 맞춰야 하기 때문입니다. 불행히도 기능 테스트에서 일부 에지 케이스가 누락되었으며 이는 테스트넷에서도 포착되지 않았습니다. 메인넷에 v19를 활성화하려는 시도가 이들 에지 케이스 중 하나에 부딪혔으며 메인넷이 블록 생성을 멈추었습니다. 이를 해결하기 위한 중간 솔루션으로 v19.1.0이 릴리즈되었으며, 이로써 v19 하드 포크를 위한 시그널이 6월 14일까지 연기되었습니다.
이와 같은 이슈를 해결하기 위해, 우리는 내부 데이터베이스에서 직렬화되는 방식을 포함, BLS 공개 키가 처리되는 방식에 관해 다시 작업하고 있습니다. 이는 이전 버전으 대시 코어와 호환할 수 없게 만들며, 이로써 DB 마이그레이션 경로가 모든 최신 버전에 구현되었습니다.
라이트 클라이언트에 마이그레이션과 과거 데이터 지원 개선
부수적으로, v19 하드포크 이슈를 해결하기 위한 솔루션 구현이 모바일 지갑에서 v19 마이그레이션을 단순화하는 길을 열게 되었습니다.
이전 구현에서는 v19 포크 시점에 4,000개 이상의 공개 키를 변환해야 했으며, 이는 10-15초 혹은 그 이상이 소요되었습니다. 또한 v19 하드포크 이후, 블록이 v19 하드포크 이전의 마스터노드 목록을 요청하는 경우 운영자 키가 기본 BLS 스킴에 들어가야 했으나, 당시 코인베이스 거래에 저장된 마스터노드 머클루트 해시가 레거시 BLS 스킴을 통해 계산되었습니다. 이로 인해 머클루트 해시를 검증하는 것이 불가능했습니다.
이를 해결하기 위해, mnlistdiff p2p 메시지의 모든 엔트리에 새로운 필드 n버전이 도입되었습니다. 이 필드는 메시지를 탈직렬화 할 때 레거시와 베이직 중 어떤 BLS 스킴이 사용되어야 할 지를 결정합니다. mnlistdiff 메시지의 n버전 자체는 더이상 스킴을 지정하지 않으며, 언제나 1로 지정되어야 합니다.
라이트 클라이언트의 믹싱 지원 개선
dsq와 dstx 메시지의 최근 변화를 통해 masternodeOutpoint 대신 proTxHash가 사용되었는데, 이로써 모바일 클라이언트는 이들 메시지와 관련된 마스터노드를 결정하기 위해 mnlistdiff 메시지로부터 마스터노드 목록을 가져오게 되었습니다. 일단 v19 하드 포크가 활성화되면, dsq와 dstx 메시지는 proTxHash에 기반을 두게 되는데, 이로써 모바일 클라이언트가 이를 검증할 수 있게 됩니다.
새로운 서명 없이 계속해서 체인락스 유지
이 버전 이전에 체인락스는 활성화 혹은 비활성화만이 가능했습니다. 그러나 이번 버전부터는 SPORK_19_CHAINLOCKS_ENABLED 설정을 할 수 있게 되면서, 0이 아닌 값으로 설정하여 새로운 체인락스 서명을 비활성화하는 동시에 가장 잘 알려진 체인락을 적용하는 것이 가능해졌습니다.