Lunie: Create transactions cross networks

[faboweb]

Is your feature request related to a problem? Please describe.

Different networks have different structures for the transactions we need to sign client side. Serving these transactions from the server would impose a risk to the client. A man in the middle could serve a malicious transaction/transaction constructor and therefore let the user sign something he doesn't want to sign.

Describe the solution you'd like

I propose we create a set of transaction types we use in the FE (interface).
Then we map those transaction types to constructors that will return the tx jsons for the individual networks. The constructors should in the best case all take the same parameters. I.e. for send: senderAddress, receiverAddress, [amount, denom].
To leverage networks being based on Cosmos being very similar, I propose we inherit the transaction constructors from a cosmos parent and only overwrite/change certain properties. One example is, that Terra uses the transaction type core/MsgSend and cosmos hub uses cosmos-sdk/MsgSend for the structurally identically send transaction.

All those constructor classes should be conditionally loaded via html5 import to reduce the initial load of the app (may be overkill as it is only a couple of lines of code).

MessageConstructor.js should be the entry point to all those constructors. This way in the rest of the code we only need to deal with one entry point.

To be able to scale better, we could serve the name/path of the message constructor class per network from the API.

A list of the transaction types:

• Send
• Stake
• Unstake
• Restake
• Create proposal
• Vote on proposal
• Deposit on proposal
• Withdraw Reward

[Bitcoinera]

Regarding the transactions list, should we also have Receive as a type? I guess not since following that logic we would also have a ReceiveStake type...

So Receive will be just a display thing, when the to field matches the user address.

Also, just to complete a bit more the transaction types list:

• Edit Validator (includes "Change Commission Rate"? I think is a good idea)
• Create Validator
• Unjail // this one is not present in all networks, same as "Vote on proposal", but it doesn't matter
• Withdraw Reward
• Open a Proposal // same

Another thing I'd like to point out:
maybe to make it more broader we could convert Restake to Stake with limitations or Restricted Stake, for the sake of simplification. And it would be exactly the same than a Stake transaction, only that it would contain some kind of counter field, to keep track of when the transaction is blocked (and this counter number is what would change from one network to another).

[faboweb]

Edit Validator (includes "Change Commission Rate"? I think is a good idea)
Create Validator
Unjail // this one is not present in all networks, same as "Vote on proposal", but it doesn't matter

those are not available to be used from within Lunie right? this issue is about creating and signing transactions ;)

I added the withdraw tx. thanks. the proposal tx was already on the list.

[faboweb]

maybe to make it more broader we could convert Restake to Stake

might make the implementation per network more complicated, but would be a nice experiment to see

convert Restake to Stake with limitations or Restricted Stake, for the sake of simplification. And it would be exactly the same than a Stake transaction, only that it would contain some kind of counter field

is the problem you are trying to solve, to prevent the user to do a restake when his limit is reached? where do you get the counter from? thinking: this is mainly a Cosmos problem. how do we map this to other networks?

[Bitcoinera]

Edit Validator (includes "Change Commission Rate"? I think is a good idea)
Create Validator
Unjail // this one is not present in all networks, same as "Vote on proposal", but it doesn't matter

those are not available to be used from within Lunie right? this issue is about creating and signing transactions ;)

Wow, you are right! Hehehe :sweat_smile:

Didn't realize until now. Would be good to add those in the future though, no?

Get all the functionality from the CLI but within a cool interface :muscle:

[Bitcoinera]

is the problem you are trying to solve, to prevent the user to do a restake when his limit is reached? where do you get the counter from? thinking: this is mainly a Cosmos problem. how do we map this to other networks?

Yes, maybe this is not so useful after all... since we just need to display the error message from the network and the user will know what is going on :thinking: ...

Although it would be nice for the users to have some index in the interface telling them how many moves they have left, don't you think? Otherwise they need to go somewhere else to look for it or keep the count on a notebook or something :laughing:

I guess that we would need to keep these counters in our DB (not easy)... or talk with the Cosmos people so they add it in their data. Is there nowadays no data for this available by REST/RPC call?

[faboweb]

Get all the functionality from the CLI but within a cool interface 💪

so far we are user focused not validator focused. some form of focus. validators also tend to use the CLI for perceived security, right?

[faboweb]

Although it would be nice for the users to have some index in the interface telling them how many moves they have left, don't you think?

I agree! But would be good to model this in a standard way. How does this look in Livepeer?

[faboweb]

I guess that we would need to keep these counters in our DB (not easy)... or talk with the Cosmos people so they add it in their data. Is there nowadays no data for this available by REST/RPC call?

There is a way to access that data:
https://cosmos-hub-3.lunie.io/staking/redelegations?delegator=cosmos1zsdkpavz8mjtnced334mrmys8y925twlu44276

[Bitcoinera]

Although it would be nice for the users to have some index in the interface telling them how many moves they have left, don't you think?

I agree! But would be good to model this in a standard way. How does this look in Livepeer?

I think there is not limit in Livepeer. I am reading here and I don't see any: https://readthedocs.org/projects/livepeer/downloads/pdf/latest/

This is the only thing it says:

"You will not yet be able to access your token while it’s unbonding for the length of the UnbondingPeriod. You can rebond during this period to the same or a different transcoder."

[Bitcoinera]

Get all the functionality from the CLI but within a cool interface muscle

so far we are user focused not validator focused. some form of focus. validators also tend to use the CLI for perceived security, right?

Yes, you are right. Probably not so many of them are interested/need this kind of interface. Or don't trust it, which makes sense.

This might change though in more democratic networks like Polkadot, maybe? Where there are no limits to how many validators there can be, anyone can become one. There could be some "hobby" validators showing up there.

@mariopino what do you think? Would yourself use an interface like Lunie to operate as a validator? Maybe just in testnet? :thinking:

[mariopino]

@mariopino what do you think? Would yourself use an interface like Lunie to operate as a validator? Maybe just in testnet? 🤔

Probably I would use Polkadot JS and a rpc client to operate my validator as I currently do. They are a large list of operations to operate a validator such as changing staking rewards target account, change commission, change identity (finally implemented in Polkadot), change session keys and start/stop validation. In my opinion probably better to focus on standard users, a more broad market than a few hundred of validator operators.

[Bitcoinera]

@mariopino what do you think? Would yourself use an interface like Lunie to operate as a validator? Maybe just in testnet? thinking

Probably I would use Polkadot JS and a rpc client to operate my validator as I currently do. They are a large list of operations to operate a validator such as changing staking rewards target account, change commission, change identity (finally implemented in Polkadot), change session keys and start/stop validation. In my opinion probably better to focus on standard users, a more broad market than a few hundred of validator operators.

Yes, you are definitely right. Thank you for that insight