Skip to content

Instantly share code, notes, and snippets.

@bas-vk

bas-vk/RPC client

Last active July 29, 2016 11:18
Show Gist options
  • Save bas-vk/4c2a6f18ee4e9b98c6453edbcdc26532 to your computer and use it in GitHub Desktop.
Save bas-vk/4c2a6f18ee4e9b98c6453edbcdc26532 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
RPC client
Are these necessary? They can be implemented fairly easy by a client that needs it. If so can we use uint for the index.
TransactionInBlock(ctx context.Context, blockHash common.Hash, index int) (*types.Transaction, error)
ReceiptInBlock(ctx context.Context, blockHash common.Hash, index int) (*types.Receipt, error)
BalanceAt(ctx context.Context, account common.Address, blockNumber *big.Int) (*big.Int, error)
PendingBalanceAt(ctx context.Context, account common.Address, blockNumber *big.Int) (*big.Int, error)
Instead of adding a special method for pending can't we just use the block number to specify pending?
Currently we have -1 and -2 to indicate the pending and latest block in the RPC interface.
Maybe introduce 2 constants for the pending and latest block.
Also, what if the user used nil for the block number. Is that the pending state?
Would be nice if something like `debug.traceTransaction` is available.
Q: CallContract has many parameters to configure the EVM. Passing all options individually is inconvenient and not future-proof, a struct would be better. We could add a struct describing calls to core/types.
Instead of passing a struct as option for the CallContract we could do something like: http://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment