Open branciard opened 5 years ago
Thanks for formulating this in such useful manner!
Do you want this feature to be work with the existing ERC20 tokens or we can assume that we always work with an ERC677 token on the Foreign side? It will get rid of necessity to change the token bridge side. Also it will imply that user will not need to claim tokens manually (no changes on the monitor side is required as well).
If we are going to operate with existing ERC20 tokens, we can consider to introduce a new functionality when the validators are looking for the Transfer
for accounts that are not whitelisted and then provide confirmations to refund assets (minus a fee): as soon as N confirmations received, the assets are returned to the same account that sent them initially.
The bridge monitor could observe a situations when only few confirmations received (e.g. the account was added to the white list just after transferring tokens) and report about such cases as so the admin could resolve the issue manually.
I have one question for the notes you published above:
Transfer affirmation request (erc20 or native) from home chain to foreign chain will be always possible.
Do you mean it will be possible by any account even if it is not whitelisted?
Thank you for your feedback!
Yes on the foreign side, it is an existing ERC20 token that does not implement ERC677 standard.
For those that implement ERC677, if I understand correctly, this whitelisting of address logic could be directly implemented in the Receiving contract with address from
filtering of the onTokenTransfer function
?:
function onTokenTransfer(address from, uint256 amount, bytes data) returns (bool success).
By reverting at this moment, no Transfer
event and so no need to do any things else.
For existing ERC20 token, I like the idea of introducing an automatic asset return back on the same address (minus bridge fees) on the foreign side. Action multi-signed by validators on the same conditions as a normal asset transfer.
To answer your question :
Do you mean it will be possible by any account even if it is not whitelisted?
I was thinking of case when an address, previousely whitelisted, has a balance on the home side. If a this address is then remove from the whitelist. To not have his balance prisonned on the home side. Bridge must assured transfer from home
to foreign
as usual even if this address is not currently whitelisted for transfering from foreign
to home
.
So, we are currently agreed on the vision of what we would like to achieve. Great!
It means that we need to implement: poa-bridge-contracts
Board
Contract with the following methods:
native-to-erc20
mode:
onTokenTransfer
should use the Board contract to check if the transaction sender is whitelisted and if it is not to revert the transaction.We need to consider methodically cases
token-bridge
Transfer
events to:
Transfer
events only from the watcher described in 1.bridge-monitor
Transfer
was not refund.bridge-ui
Transfer
operations for the end user if it is not whitelisted. Did I miss something?
Thank you for the synthesis, it looks to cover all things!
For token-bridge description part, for 1. and 2. point, is it only one watcher that cover both functionalities: watching the update of the whitelist and also watch transfer Event, or 2 different watchers containers that must, at some point, communicate to each other to know the filtering policy? And if so, how do they communicate with each other?
For this new Transfer watcher, do we create a new different case like affirmation-request-filtered-watcher
or do we configure the existing affirmation-request-watcher
to cover all cases?
Redis
to keep the actual whitelist. The watcher that looks for the whitelist updates in the contract will do the following:
Redis
.So, the watcher that monitors Transfer
will get all corresponding new events. If new there are new events it will:
ok, make sense to use Redis
for the whitelist shared state between containers. ok for one transfer event watcher covering both.
@branciard so actually the question is whether you are able to implement this?
Yes, I will try to implement those functionalities listed above. It may take me a bit more time ( maybe 2 months from now) as I must also continue to learn and master all part of bridge code to implement this feature correctly and test this new functionality fully then after. I will rebase on develop branches during this time to keep me updated. I will contact you if I have questions along the process. Is it ok for you?
@branciard thanks for such involvement! Yes, me personally and @patitonar will support you as much as we can. I am in GMT+2 timezone, Gerardo is in GMT-3 (I think). You can use also Telegram (https://t.me/AlexanderKolotov) to contact to me quickly.
Great! thank you, I will let you informed.
Hi, Here spec proposal to implement a consortium bridge as described here : https://forum.poa.network/t/consortium-bridge/1739.
A consortium Bridge will introduce a whiteListing of ethereum address that will be allowed to transfer asset from the
foreign
chain to thehome
chain according to the current state in a foreign chain whitelist smart contract.Transfer affirmation request (erc20 or native) from
home
chain toforeign
chain will be always possible. If a user has move asset before being removed from the whitelist by admin, The user will be able to withdraw asset (home
toforeign
) but not deposit asset any more (foreign
tohome
).The deployment of this whiteListing should be optional. This will be materialized by a contract (like the optional
feeContract
for instance) that can be set to null (0x0) for an open bridge as today.Proposal for this contract name : Border.sol or BorderPoint.sol, BorderCrossing.sol, BorderCrossingPoint.sol, Frontier.sol ... We will name it
Border Contract
in the following text.The
Border
Contract must be upgradable. (removed (0x0) or replace by a new one)The
Border
Contract state will be stored in the foreign chain and not in the home chain. In order to have a non-repudiation assured. As the home chain state maybe not accessible by everybody.This whitelist in
Border
Contract will be checked and affirmationRequestWatcher bridge component may filter events received.The whitelisting check is activate by a configuration on bridge conf too:
CHECK_BORDER_ACTIVE=true|false
If the bridge cannot access the smart contract whitelist, filtering is done by default. So this is why a config can be set :CHECK_BORDER_ACTIVE = false.
In this case, no check to retrieved theBorder
Contract form theforeign bridge
contract and no check of the whitelist in theBorder
Contract. All this to be sure to not have rpc failure network from the foreign web3 that will ended to do a filtering by default... Admin must setCHECK_BORDER_ACTIVE
tofalse
in bridge config when a public bridge mode is wanted as today.AffirmationRequestWatcher
filtering action will introduce a balance desynch detected by the bridgeMonitor ? In this case, all filtering must be records in logs, in order to administrator to detect if balance desynch is cause by normal filtering or real problems. In this log, Admin must be able to have all data to refund user in case of filtering done, if the user claimed his locked asset on the foreign bridge contract. In this case, the use ofclaimTokens
to refund ?: https://github.com/poanetwork/poa-bridge-contracts/blob/119-Epic-rewards-for-bridge-validators/contracts/upgradeable_contracts/BasicBridge.sol#L130Note: This
Border
Contract is not a membership contract. It is an authorization to currently bridge asset in one direction foreign to home. By "currently", we means the current state of the whitelist in foreign chain, not the time of erc20 or native transfer transaction done by the user. Timing may differ a bit.Note : A blacklist strategy for the
Border
Contract is not usefull as a user can change wallet at any time to easily pass the bridge.Interface of BorderContract :
Must generate an
event RecipientAllowanceAdded(_recipient)
Must generate anevent RecipientAllowanceRemoved(_recipient)
addRecipientAllowance and removeRecipientAllowance
methods access by the bridge admin account only. The methodisAllowed(_recipient)
is public.Border Contract implementation must have a allowedRecipient mapping.
Or list must be store in EternalStorage ? (like the validatorsList) and used of :
Or maybe a quick solution with no smart contract involved ? Only provide a config list of address used to filter or not in
affirmationRequestWatcher bridge
component.This is a starting point ideas for a consortium bridge. Open to others architecture proposals.