There is a need for having unknown users, that have never interacted with RChain / the blockchain, being able to deploy. Four propositions/way ofhow to do this have been discussed. Two of them are ready, and can be done with existing rnode.
1 - (ready) Prepaid with public keys list
The dapp develoepr knows the public keys:
Then just send REV to each public key
cons:
you have to monitor the money left for each, and eventually refill individually
can be abused, a malicious public key can do a REV transaction and get around initial dapp
pro
no need to change existing rnode/rholang
2 - (ready) Delayed deploy
(1) The user
create an account to centralized service
create a signed deploy (metamask, dappy, else)
(2) centralized authentication (email, captcha)
(3) dapp developer fills the account with REV + deploys the deploy signed by user
pros: impossible DDOS, already possible
cons: more complicated than onchain authentication
3 - Specific rholang execution, for specific process/rholang (SRE)
The dapp developers expresses his agreement to paying for a given rholang execution after having done the proper verification (rholang)
match (*x == "valid", *process) {
(true, { "key": "value" }) => {
if (*registeredUsers < 100) {
registeredUsersCh!(*registeredUsers + 1) |
// here dapp developer can send REV to deployed if he wants to
payForCurrentDeploy!(
*dappDeployerId,
{
limit: 2000 (phlo or dust ?),
allowVault: true/false
})
}
}
_ => {
Nil
}
}
cons:
risk for DDOS
pros:
no need to know public key in advance
only a precise operation/rholang/deploy is permitted
no incentive for hackers, no REV
4 - Pay after
a deployer starts with negative balance, the deploy is recorded / the change is saved ONLY IF the balance becomes positive or 0 at the end of the deploy
There is a need for having unknown users, that have never interacted with RChain / the blockchain, being able to deploy. Four propositions/way ofhow to do this have been discussed. Two of them are ready, and can be done with existing rnode.
1 - (ready) Prepaid with public keys list
The dapp develoepr knows the public keys:
Then just send REV to each public key
cons:
pro
2 - (ready) Delayed deploy
(1) The user
(2) centralized authentication (email, captcha)
(3) dapp developer fills the account with REV + deploys the deploy signed by user
pros: impossible DDOS, already possible cons: more complicated than onchain authentication
3 - Specific rholang execution, for specific process/rholang (SRE)
The dapp developers expresses his agreement to paying for a given rholang execution after having done the proper verification (rholang)
cons:
pros:
4 - Pay after
a deployer starts with negative balance, the deploy is recorded / the change is saved ONLY IF the balance becomes positive or 0 at the end of the deploy