icon-project / btp-product Goto Github PK

• Design APIs between internal modules of GOLOOP
• Design external server APIs for RELAY

This might already be done, but need to confirm if any changes must be done for BTP 2.0.

@mksong-icon - does the current BMR need any changes? If not, then we can close this issue

It doesn't need to be long. It should be mostly technical, focused on how BTP messages work, how it's secured, the role of the Relay, the role of each contract, how each contract actually works (i.e. how blockUpdate is performed).

As opposed to wrapping an NFT on its native chain, then minting on destination, it should have a burn functionality to never exist on more than one network.

Example:

• Originally minted on Chain A
• To transfer to Chain B, burn on Chain A, send proof to chain B, then mint on Chain B
• To transfer to Chain C, Burn on CHain B, send proof to chain C, then mint on Chain C
• It never exists on two chains

• BMR Implementation for BTP2.0 (Sender/Receiver)
• BMR Upgrade for supporting BTP 2.0
• BMV Development ( Java BMV / Solidity BMV )

Example would be the OmniChainToken.sol

As opposed to wrapping a token on its native chain, then minting on destination, it should have a burn functionality to never exist on more than one network.

Example:

• Originally deployed on Chain A
• To transfer to Chain B, burn on Chain A, send proof to chain B, then mint on Chain B
• To transfer to Chain C, Burn on CHain B, send proof to chain C, then mint on Chain C
• It never exists on two chains

Eric and Cyrus are working on creating more recognizable based on industry standards for BTP

Link to the logic:

icon-project/btp#65 (comment)

Rationale
It is desirable to not be dependent on specific consensus mechanisms. We can assume that blocks with some threshold number of confirmations are on the longest chain, and provide some backup mechanism to restore state to a specified block height in the event that the longest chain changes.

Acceptance Criteria

• Discuss feasibility of supporting probabilistic finality
• Identify state restoration mechanism
• Confirm whether or not we will support probabilistic finality in BTP 2.0

Open Questions
Please post any relevant questions as a comment in the issue thread

• Sender / Receiver implementation in BMR

We need to specify what the expected behavior is in circumstances where input data is invalid, and create unit test cases for this.

• BTP Benefits

Let's add another value in the database for each entry. We need two types of fees, one for the BTP protocol and one to compensate Relays for the cost of processing the message. It can be very simple for now, but want the data structure to be there from the start. For example:

feeObject:
Dest Chain = Harmony
relayFee = .25 ICX
protocolFee = 0.01ICX

Relay fee goes to Relay, protocol fee goes to BTP protocol (eventually, Fee Aggregator SCORE)

For now, we don't need actual destinations of these fees. Just an admin function like setRelayFeeAddress and setProtocolFeeAddress.

This might already be done, but need to confirm if any changes must be done for BTP 2.0.

@mksong-icon - does the current BMC need any changes? If not, then we can close this issue