# Future-Bridge-Prototype

pragma solidity ^0.8.0;

contract FutureBridge {
	// The group order of secp256k1
	uint256 public constant ORDER = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141;

	// A prefix that represents the key operation update
	uint8 public constant UPDATE_KEY_OPERATION_PREFIX = 0;

	// The current circle's public key's parity value
	uint8 public parity;
	// The x-coordinate of the current circle's public key
	uint256 public px;

	constructor(uint8 _parity, uint256 _px) {
		parity = _parity + 25;
		px = _px;
	}

	// @param _parity is the parity value of the new public key
	// @param rAddress is the address form of the commitment R
	// @param _px is the x-coordinate value of the new public key
	// @param s represents the Schnorr signature generated by the current circle's private key
	function updatePubkey(uint8 _parity, address rAddress, uint256 _px, uint256 s) external {
		require(
			verify(rAddress, s, keccak256(abi.encodePacked(UPDATE_KEY_OPERATION_PREFIX, _parity, _px))),
			"FutureBridge: Public key update fails, the current circle's signature is invalid."
		);
		parity = _parity + 25;
		px = _px;
	}

	// @param rAddress is the address form of the commitment R
	// @param s represents the Schnorr signature generated by the current circle's private key
	// @param messageHash is the hash from the original message
	function verify(address rAddress, uint256 s, bytes32 messageHash) public view returns (bool) {
		require(rAddress != address(0), "FutureBridge: Invalid address of R");

		uint8 _parity = parity;
		uint256 _px = px;

		uint256 c = uint256(keccak256(abi.encodePacked(
            bytes32(0x42414e442d5453532d736563703235366b312d7630006368616c6c656e676500),
            rAddress,
            _parity,
            _px,
            messageHash
        )));

		uint256 spx = ORDER - mulmod(s, _px, ORDER);
		uint256 cpx = ORDER - mulmod(c, _px, ORDER);

		// Because the ecrecover precompile implementation verifies that the 'r' and's'
		// input positions must be non-zero
		// So in this case, there is no need to verify them('px' > 0 and 'cpx' > 0).
		require(spx != 0, "FutureBridge: Invalid value of s*px");

		return rAddress == ecrecover(bytes32(spx), _parity, bytes32(_px), bytes32(cpx));
	}
}

<div align="center">

[](https://opensource.org/licenses/Apache-2.0)

</div>

**Disclaimer:** This project is still in its early stages of development and is considered a prototype. Please refrain from using it in production.

The FBP is a new relaying scheme that connects EVM networks with
the Band protocol's chain in a more efficient way than the current
Bridge smart contract. It is based on threshold signature technology
and a custom signing procedure that reduces the size of the proof and
the number of verification operations, resulting in significant gas
savings.

---

## Background
The current Bridge smart contract contains a large number of EVM operations
for doing lite client verification, which causes the gas used in the
verification to be extremely high. This is mainly due to storing and
reading validators with voting power, verifying numerous signatures,
Merkle trees hashing, and Tendermint's struct encoding.
To address this issue, the FBP was developed.

## Installation
First (if you don't have Foundry) run the command below to get foundryup,
the Foundry toolchain installer:

curl -L https://foundry.paradigm.xyz | bash

## Testing

forge test -vv

## Features
The FBP is built on threshold signature technology and a custom signing
procedure. This provides several advantages, including:

- Reduced gas usage: The custom signing procedure used in the FBP
significantly reduces the amount of gas required for verification,
resulting in cost savings for users.
- Enhanced decentralization: The threshold signature mechanism employed
in the FBP further improves decentralization by eliminating the need for
a multisig wallet, which was previously utilized to regulate the Bridge
contract. This is because any parameter update can be accomplished with
a single threshold signature as proof, avoiding the requirement for
numerous parties to sign off on changes. This makes the Future-Bridge
more decentralized and less reliant on a central authority, which is a
vital feature for many blockchain users.

## Contributing
Contributions to the FBP are welcome and encouraged. If you have any suggestions or feedback, please open an issue or submit a pull request. We appreciate your contributions and look forward to working with you to make the FBP even better.