이해 되지 않는 부분은 caver.wallet.updateKeyring 으로 multisig 업데이트 한 후,
갱신된 keyring을 가지고 transaction sign 및 sendRawTransaction을 보내는
예제 소스인데요, multi sig에 대한 예제 소스라고 하기에는 복사&붙여넣기 느낌이 너무 납니다.
Key를 3개로 ( weight 2 , 1 , 1 ) 분할해서 최소 2개의 키로 sign을 해야
Transaction send를 할 수 있는 것처럼 설명이 이어지다가,
갑자기 모든 key를 다 가지고 있는 keyring으로 sign 한번만 하고,
Tx send를 하는 예제인데요,
문의 내용은 아래와 같습니다.
모든 key를 가진 keyring이 등록된 caver.wallet은
한번만 sign을 하더라도 3개의 서명이 다 붙는 것인지요?
multisig로 key 여러 개 사용하도록 갱신하는 경우는 권한의 분배와 확인 절차, 정책 수립 등의 목적성이 다분한데요…Key를 각 권한자에게 분배하려면 가중치에 맞게 Private key를 전달하게 될 텐데요.
a. Keyring의 생성 과정 예제 소스
b. Kaikas 등록 절차
이 내용은 어디에서 찾을 수 있을까요?
서명의 가중치 합이 Threshold 를 충족하지 못한 Transaction은
Klaytn의 어디에 등록이 되는 것인 지, 어떤 SDK API를 통해서 조회하고 승인할 수 있는지요?
등록되지 않는다면…
별도의 DBMS와 API 서버를 구축 개발해야 최종 서명자에게 전달할 수 있겠군요?
현재의 caver는 각 키타입의 sign을 호출하게 되면 내부적으로 가지고 있는 keyring에 있는 모든 키들을 이용해 서명을 진행하도록 구현되어 있습니다.
현재 web3 SDK를 이용해 클레이튼의 다양한 키타입을 사용하실 수 있도록 SDK가 개발되고 있습니다. 상반기 내로 완성을 목표로 하고 있으며 완성후에는 기존 Web3 SDK (web3py, web3js, web3j, ethersjs)로 쉽게 이용하실 수 있는 예제와 시나리오 등이 제공될 예정입니다.
현재 threshold를 충족하는 signature를 포함하고 있지 않다면 노드에서 reject되고 있습니다. 이를 편리하게 사용할 수 있는 것들을 고민하고 있습니다.
좋은 의견이나 아이디어 있으시다거나 더 궁금하신점 있으시면 지속적으로 소통했으면 좋겠습니다.
현재의 caver 버전에서도 키타입별로 사용이 가능합니다. 제가 말씀드린 부분은, 다른 web3 sdk에서도 클레이튼의 키타입을 사용할 수 있도록 개발을 하고 있다는 점 입니다.
그리고 말씀주신대로 현재 multisig tx에 대한 pending처리는 플랫폼 내에서 처리가 안되는게 맞구요 별도의 백엔드를 구축해야 가능합니다. 향후 클레이튼에서 이러한 부분을 쉽게 이용할 수 있도록 백엔드 서비스 또는 플랫폼에서 지원하는 방안 등을 고민하고 있습니다.
