CKB Transaction Co-Build Protocol details an off-chain protocol for multiple parties to collaboratively create CKB transactions. It encompasses standard procedures and data formats for transaction building and signing. In real-world scenarios, interactions between wallets and dApps necessitate functionalities like account retrieval, address synchronization, and message signing. Moreover, wallets need to emit relevant events when changes occur in addresses or accounts, for dApps to subscribe to. Additionally, the design and validation of communication methods between wallets and dApps are also essential.
Get the Address list by specific lock script base, in the format of <code_hash>:<hash_type>.
Parameters
{
[<script_base>] :{
page: {
size: number // the size of address list to return
before: string // used as the end point of the returned address list(excluded)
after: string // used as the start point of the returned address(excluded)
},
type: 'generate' | 'all' // set 'generate' to generate new addresses if necessary; set 'all' to get existent addresses
}
}
Communicating between web pages via URL, primarily used in JoyID scenarios.
Communicating between web pages via post message, primarily used in JoyID scenarios.
Communicating between applications via deep link, mainly for app scenarios.
Using WebRTC to facilitate communication between dapps and wallets.
The CKB Transaction Co-Build Protocol mentions that the size of a CKB transaction varies depending on its content—it could be due to a large number of inputs/outputs, or substantial output data, meaning the size isn't constant. Per the CKB protocol's limitations, a CKB transaction could reach up to 600KB under extreme conditions. This implies that the BuildingPacket's size could be close to or even exceed 600KB, considering it also includes other components like Message, ScriptInfo, etc.
The first three methods all face the issue of having limitations on the size of data that can be transferred. Therefore, we can consider using WebRTC for communication.
Implement WebRTC for establishing a connection and communication:
Create RTCPeerConnection:
const peerConnection = new RTCPeerConnection(configuration);
Set Up ICE Candidate Event:
peerConnection.onicecandidate = event => {
if (event.candidate) {
// Send candidate to remote peer
}
};
Create an Offer (Initiator) or Answer (Receiver):
Offer:
peerConnection.createOffer().then(offer => {
return peerConnection.setLocalDescription(offer);
}).then(() => {
// Send the offer to the remote peer
});
Answer:
peerConnection.setRemoteDescription(remoteOffer).then(() => {
return peerConnection.createAnswer();
}).then(answer => {
return peerConnection.setLocalDescription(answer);
}).then(() => {
// Send the answer to the remote peer
});
Exchange ICE Candidates:
Exchange the ICE candidates received from onicecandidate event with the remote peer.
Data Communication:
For data transfer, use RTCDataChannel:
Motivation
CKB Transaction Co-Build Protocol details an off-chain protocol for multiple parties to collaboratively create CKB transactions. It encompasses standard procedures and data formats for transaction building and signing. In real-world scenarios, interactions between wallets and dApps necessitate functionalities like account retrieval, address synchronization, and message signing. Moreover, wallets need to emit relevant events when changes occur in addresses or accounts, for dApps to subscribe to. Additionally, the design and validation of communication methods between wallets and dApps are also essential.
Specification
Accounts
Methods
ckb_getAddresses
Get the Address list by specific lock script base, in the format of
<code_hash>:<hash_type>
.ckb_signTransaction
Get a SignedTransaction over the provided instructions.
ckb_sendTransaction
ckb_signMessage
Get a signature for the provided message from the specified signer address.
Events
accountChanged
Emit the event when the account changed
addressesChanged
Emit the event when addresses changed
compound types
Address
Message
Transaction
SignedTransaction
Communication Method
Currently known methods include:
The CKB Transaction Co-Build Protocol mentions that the size of a CKB transaction varies depending on its content—it could be due to a large number of inputs/outputs, or substantial output data, meaning the size isn't constant. Per the CKB protocol's limitations, a CKB transaction could reach up to 600KB under extreme conditions. This implies that the BuildingPacket's size could be close to or even exceed 600KB, considering it also includes other components like Message, ScriptInfo, etc.
The first three methods all face the issue of having limitations on the size of data that can be transferred. Therefore, we can consider using WebRTC for communication.
Implement WebRTC for establishing a connection and communication:
Create RTCPeerConnection:
Set Up ICE Candidate Event:
Create an Offer (Initiator) or Answer (Receiver):
Exchange ICE Candidates: Exchange the ICE candidates received from
onicecandidate
event with the remote peer.Data Communication: For data transfer, use
RTCDataChannel
:UX Design
https://vs0cjf.axshare.com/#id=psrijc&p=walletconnect-general&g=1