hermeznetwork / hermez-go-sdk Goto Github PK

Have methods for creating transactions:

// Generate L2 txs easy mode (fee and nonce calculated on behalf of the user)
func NewTransferToIdx(from, to, amount) common.PoolL2Tx
func NewTransferToEthAddr(from, to, amount) common.PoolL2Tx
func NewTransferToBJJ(from, to, amount) common.PoolL2Tx
func NewExit(from, to, amount) common.PoolL2Tx

// Generate L2 txs pro mode (fee and nonce set manually by the user)
func NewTransferToIdxAdvanced(from, to, amount, nonce, fee) common.PoolL2Tx
func NewTransferToEthAddrAdvanced(from, to, amount, nonce, fee) common.PoolL2Tx
func NewTransferToBJJAdvanced(from, to, amount, nonce, fee) common.PoolL2Tx
func NewExitAdvanced(from, to, amount, nonce, fee) common.PoolL2Tx

Method for requesting tx:

func RequestTx(tx, requestedTx) error

Method for signing:

func Sign(tx, chainID, privateKey) error

Create an atomic group (set the RqOffset, and AtomicGroupID....):

func NewAtomicGroup(txs) common.AtomicGroup

Note that all this methods are extremly easy to implement except NewAtomicGroup that it's a bit tricky due to protocol limitations on the RqOffset. Implementing this would result in a cleaner SDK where:

• Wallet and transactions are separated
• Atomic and non atomic txs are used in the same way
• Service providers (for swaps) and users have clear paths for their use cases
• Use hermez-node structs as much as possible to avoid confusion with similar structs and easier to maintain

Right now there is only one method for getting information on transactions on the pool: transaction.GetTransactionsInPool. According to the function description: GetTransactionsInPool connects to a hermez node and pull all transactions in the pool, which is not true because it query the first 1000 txs not all of them. But most importantly, most of the time users will want to query just one tx base on the ID.

Pleae add the method: GetTransactionInPool that returns a single transaction based on tx ID

Avoid having custom structs just for the sake of marshaling JSONs. Note that this is needed in some cases if the hermez-node structs don't have the marshalers implemented.

• AtomicGroup
• PoolL2Tx
• AccountCreationAuth depends on hermeznetwork/hermez-node#1030

The function AtomicTransfer should receive the txs already signed, as the common case will be for no single entity to have all the related private keys to an atomic group. So this function should take care of:

• Set the RqOffset
• Set the AtomicGroupID
• Perform the HTTP POST

Of course all of this already happens, just need to change the interface of the function to have as input txs []common.PoolL2Tx.

Additionally, it would be nice to validate that:

• Txs are valid (signature is correct)
• The given set of transactions represent a single atomic group

This is actually same validations that the hermez-node will run. But I believe running the validations before sending the request may be easier to debug, and can give more info to users.

Keep in mind that the current code is actually working (I believe), so it's up to you to implement this or not, in this PR or in future ones. The only thing I would say it's mandatory is to don't sign the txs in this function, as this will make the SDK unusable

Related to #2 (comment)

In many parts of the code strings are used instead of the actual types, this leads to all sorts of errors and users need to have a deeper understanding of everything. For instance should I send "hez:0x347943..." or 0x347943....

We should take advantage of strong types. We love Go and not JS for many reasons, and this is for sure one of them. JSON formatting should be kept at marshaling level when sending to the API or we could use String() when logging stuff, but we should avoid as much as possible this in public methods / structs.

In this drafted PR I encountered some problems precisely because of this #11