kgrgpg
commented
1 year ago Using the comments from @richard-ramos @fryorcraken @oskarth as follows:
From @richard-ramos - Maybe it's too early for discussing technical implementations, but if a new token is created (in options 4 and 5), consider adding support to https://eips.ethereum.org/EIPS/eip-2612 so it's not necessary to do an approve transaction as a step previous to depositing the tokens.
For option 1, if SNT is the token to use, maybe a helper function function receiveApproval(address _from, uint256 _amount, address _token, bytes memory _data) public { could be added to allow using approveAndCall from https://eips.ethereum.org/EIPS/eip-1363, and this way also avoid having to do 2 separate transactions
From @fryorcraken - Is there a difference in the respective contract API between an ERC-20 token and WETH? I am not sure to understand why WETH is a case set apart
I would not scope the minting of token in this work. I think it makes sense to only scope
Accept an existing ERC-20 token (like SNT, etc.) as the ONLY membership deposit for the RLN contract.
Other use cases may raise in the future (several ERC-20, ERC-20 token + Eth with discount on token, etc) but they can left out of scope at this stage.
From @oskarth - I would not scope the minting of token in this work. I think it makes sense to only scope
Accept an existing ERC-20 token (like SNT, etc.) as the ONLY membership deposit for the RLN contract.
Agree.
To me, ERC20 should basically be a parameter when you deploy the contract. So the contract itself is agnostic to ERC20 address, and deployment of it is a separate concern.
It might make sense to have two contracts. One using only ETH, and the other being parametric ERC20. Then depending on what platforms/networks want, they can deploy a specific instance of some ERC20 token.
The decision to point an implementation to a specific contract instance is then a separate discussion, so you can imagine that in the future people using the Status protocol would instruct nwaku to use the SNT ERC20 address, but a different platform could conceptually deploy their own thing and point nwaku to that.
These are great points and I agree! Big difference for usability. Just to check:
Would this work for any ERC20 token? Or does EIP-1363 support have to be added to the actual "ERC20" token contract and not just in the RLN contract?
If the token contract needs native support for it, could this easily be detected and tokens that support EIP-1363 can use one-step approveAndCall, with older versions requiring approve and call as two steps?
richard-ramos
The currently used RLN membership contract as implemented in https://github.com/kgrgpg/rln/blob/main/contracts/Rln.sol , accepts the payment in ETH for register function. This acts as the stake of the member in the RLN group that gets slashed when the member misbehaves like spamming the peer to peer network.
There have been request to support ERC-20 tokens as membership deposit for the contract. But detailed discussion and implementation over the said functionality has not taken place and this issue will address it.
The implementation of ERC-20 token can take place in multiple ways. Some of them are listed as follows and require different technical implementations in Solidity smart contracts:
The complexity of the implementation goes higher as we move down the above list. We need to discuss the most valid ones and move towards them.
Note that this issue has been cloned from https://github.com/status-im/nwaku/issues/1058 so that it can be under the correct organisation and repo banner.