DevTool SPS proposal: steem trx finder

in #steem5 years ago (edited)

block-chain-3513216_1920.jpg
Image source pixabay

Greetings,

Some of you guys know me already, some not, I have been working and collaborating in the STEEM dev ecosystem for more than 2 years.

This nodejs/Javascript tool is half-way done, and was born out of pure necessity. However, there are still plenty of things to be done.

The public npm package is already published.

If you think this is a good tool, please vote me. The development should only take one more week to finish everything.

Why would a developer need the full Transaction object?

Say, for instance, that a developer needs to verify the account signer of a vote. He would go request to the rpc-api endpoint get_account_historyfor the desired account, and loop over until finding the right match.

Guess what? The returned "pseudo-transaction" has no signature. Neither has extensions, ref_block_num or ref_block_prefix.

So basically, no signature, no way to know who is the actual signer. Developers have currently a big trouble linking operations with the full Transaction object.

Purpose

STEEM rpc-api database endpoint get_account_history does provide only a pseudo-transaction object. This is the form of the returned object:

[
  31896,
  {
    trx_id: '268de18b9d381eeaa71419c1454f5f229c785235',
    block: 35683670,
    trx_in_block: 19,
    op_in_trx: 0,
    virtual_op: 0,
    timestamp: '2019-08-19T08:15:21',
    op: [ 'vote', [Object] ]
  }
]

This pseudo-transaction object is missing valuable information such as:

  • Signature
  • extensions
  • expiration
  • ref_block_num
  • ref_block_prefix

If you need the full trx object, this library will help you.

Under the hood

This tool is basically iterating over the blocks looking for the right time interval. We know each block happens every 3 seconds, so the algorithm does some date approximations searching in the blocks archive until finding the right one. Once the right block has been found, the full trx can be returned.

Use

This library has been design with async requests in mind.

If you want to initialise a dsteem client:

var dsteem = require('dsteem')
var client = new dsteem.client(rpc_node_address)

Each method call requires a client instance passed as argument.

There are two methods available:

  • findCommentTrx(client, author, permlink)
  • findVoteTrx(client, pseudo_trx)

Install

$ npm i steemtrxfinder --save

Configuration

TBD

TO-DO

  • Add tests
  • CLI
  • browser support
  • Add more operations support

NPM public package

https://www.npmjs.com/package/steemtrxfinder

Github

https://github.com/AusPrinzip/steemtrxfinder

Sort:  

This is unnecessary. You should use the RPC call account_history_api / get_transaction if you need the full trx. It already includes all the data you are looking for.

Seems like only your server (anyx.io) supports the call you suggest. When using steemit rpc node I get this error msg: Assert Exception:false: This API is not supported for account history backed by RocksDB

Not all api endpoints are created equal. Not all nodes support full account_history. For example, I know the minnnowsupport node doesn't support it; they sometimes forward these requests to me.

Steemit has dubbed these calls as "Working on mainnet" & "Working on testnet" so it's just a matter of finding a truly full-node endpoint.

https://developers.steem.io/apidefinitions/#account_history_api.get_transaction

Example rpc call:
curl -sd '{"jsonrpc":"2.0", "method":"account_history_api.get_transaction", "params":{"id":"55eb04e397569e27fff8fbf04841ca7c5b9e522c"}, "id":"0"}' anyx.io

Or via RESTful translation:
https://anyx.io/v1/account_history_api/get_transaction?id=55eb04e397569e27fff8fbf04841ca7c5b9e522c

Wondering why your RESTful api uses query params, instead of representing resources with URIs.

  1. because in general parameters do mean queries, they are not static resources, they are dynamic API results.
    Some do work as plain URIs, like https://anyx.io/v1/database_api/get_dynamic_global_properties, as this has no parameters.
  2. the /v1/ variant is backwards compatible and easily translatable from the original POST variant to the RESTful one. Better URIs (but breaking compatibility) can come in a v2.
    consider something like https://developers.steem.io/apidefinitions/#database_api.list_accounts
    The mapping is intuitive, instead of POSTing
    '{"jsonrpc":"2.0", "method":"database_api.list_accounts", "params": {"start":"steemit", "limit":10, "order":"by_name"}, "id":1}'
    you can instead do
    http://anyx.io/v1/database_api/list_accounts?start=steemit&limit=10&order=by_name
  3. the current steem appbase apis require the object name (e.g., as above, they require knowing "start" as well as the value associated). Including it in the request clarifies the mapping.

This is how restful implementations work typically. You have parameters to format the specific data you are interested in.

30.36$ has been spent to promote this content using Steemium.
Learn more here!

You got a 29.15% upvote from @promobot courtesy of @steemium!

To listen to the audio version of this article click on the play image.

Brought to you by @tts. If you find it useful please consider upvoting this reply.

If you can explain what does it mean, I shall flood you with STEEM brother

Posted using Partiko Android

I really need to find my old post, that is a great thing because I can make a list of old post which I want to read again and again.

What You ask for is to build full witness node with get_transaction call enabled.