coinbase / mesh-specifications Goto Github PK

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

An error's name should be concise and canonical, but sometimes it's hard to come up with a concise name that accurately describes what an error means. It would be great to express what an error means with a longer text field that can change between versions and not break any programs built against the API.

Describe the solution you'd like

Add an (optional) description field to the Error model. This can be used for the purpose of describing what an error means. It is not machine-checked and only there to help developers.

Describe alternatives you've considered

Add no new field and use code comments to express error descriptions. It seems preferable to include the descriptions in the payload of the error so clients wouldn't need to read source code.

Additional context

One version of the Mina implementation of the Rosetta spec included a misunderstanding of the details field that was co-opted to serve this purpose.

Describe the bug
The description for Transaction.Metadata contains the misspelling transactioin. https://github.com/coinbase/rosetta-specifications/blob/439b881859b0982bb6baf34a9666db1018d419f9/models/Transaction.yaml#L31

Expected behavior
Should be spelled transaction.

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

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Conflux is a high-performance public chain, we are working on integrating with Rosetta. But we have encountered a problem that is Our chain default won’t save all historical states, which means only supporting query account balance in the latest blocks for example latest 5w blocks.

If one want query balance in any block height, the fullnode’s disk storage will be very very big maybe several hundred T

So if it is Ok for the query balance Data-API only support query balance at latest 5w blocks ?

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

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

ConstructionParseResponse.signers is stated as a string but it's not clear what's expected. Thanks to @patrick-ogrady we knew it's about returning singers addresses although we were returning the signers.

Describe the solution you'd like

To clearly state what needs to be returned there.

Describe alternatives you've considered

n/a

Additional context

n/a

Is your feature request related to a problem? Please describe.
Some blockchain teams have noted that precision may be lost for int64 numbers in some clients (like JS) if a number greater than 2^53 is populated since JSON defines numbers as float64.

Example (BlockIdentifier): https://github.com/coinbase/rosetta-specifications/blob/439b881859b0982bb6baf34a9666db1018d419f9/models/BlockIdentifier.yaml#L22-L27

Describe the solution you'd like
Unfortunately, int64 is highest precision number type you can specify in OpenAPI (also not possible to use uint64). To remedy this issue, we would need to encode all int64 numbers as string.

Fortunately, this issue only will affect BlockIdentifer.Index and Block.Timestamp as all other "number-like" values that could come close to 2^53 are already encoded as strings (ex: Amount.Value). Operation.Index (which is also encoded in int64) shouldn't run into this issue as it is relative to the Transaction where an Operation is present in, not a global index.

Great work putting together a blockchain api standard so far @patrick-ogrady and co 👍

One feature I'm particularly interested in would be to generate typing info from the model files. Doing so leverages tooling many are already using, and can facilitate a much better DX.

We're already doing this @blockstack with our api layer that sits atop our code node, and publishing a package of the output types.

It's not a perfect set up. It uses a mash of npm packages, and has ran into some limitations of the JSON Schema standard. Primarily: How should you generate types with allOf and oneOf properties, as well as types with 2 or more discriminating type unions. But otherwise has served us quite well.

Would love to hear whether this has already been discussed, and thoughts on how it could fit into the Rosetta project.

Repost of coinbase/mesh-cli#63

Hi team, we have previously posted our problem on the forums and as suggested by @patrick-ogrady to open an issue for it,

https://community.rosetta-api.org/t/any-way-to-get-public-key-from-signer-package-before-combine/189

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

Our Zilliqa blockchain's signature is dependent on a Zilliqa transaction object which requires the sender public key.

Our signing process on the blockchain is as such:

1. Create unsigned transaction object
2. Convert it to a zilliqa transaction object with public key
3. Convert (2) to bytes; during the process it appends additional params such as ID, network params, etc.
4. Sign (2) to obtain a signature

This differs from the current rosetta-sdk which is:

1. Create unsigned transaction object
2. Sign (1) to obtain a signature

As a result, during /construction/submit in the construction tests, our blockchain verifies that the provided signature is always returning false and rejects them.

We wish to have access to the signer's public key at any of the Construction API steps before /construction/combine so as to use the unsigned transaction, add the public key and convert it to our transaction object before spitting out the proper “unsigned transaction” for /construction/payloads response.

Describe the solution you'd like

To have a new /construction/address to derive the public key from a given address. Think of it as a complement to construction/derive.

ConstructionAddressRequest

{
    "network_identifier": {
        "blockchain": "bitcoin",
        "network": "mainnet",
    },
    "account_identifier": {
        "address": "0x1234567890123456789012345678901234567890",
    },
    "metadata": {}
}

ConstructionAddressResponse

{
    "public_key": {
       "hex_bytes": "string",
       "curve_type": "secp256k1",
    },
    "metadata": {}
}

The new Contruction flow would be (/parse is omitted for clarity):

1. /construciton/derive
2. /construction/address
3. /construction/preprocess (public key is passed as part of metadata)
4. /construction/metadata
5. /construction/payloads (unsigned json now contains the public key)
6. (Sign with rosetta-sdk signer)
7. /construction/combine
   (the rest follows as usual)

Note: We have not consider how to incorporate this into rosetta-cli tests given that not all blockchain providers require the proposed /construction/address.

Describe alternatives you've considered
We have added our own object conversion in the keys package in a custom rosetta-sdk-go and it passes the Construction API tests.

https://github.com/teye/rosetta-sdk-go/blob/master/keys/signer_secp256k1.go#L75

https://github.com/teye/rosetta-sdk-go/blob/master/keys/signer_secp256k1.go#L143

However, this is not recommended as pointed out by @patrick-ogrady as it complicates the existing keys package.

Additional Information
https://community.rosetta-api.org/t/any-way-to-get-public-key-from-signer-package-before-combine/189

Describe the bug
All requests that only contain a NetworkIdentifier use a NetworkRequest, however, /mempool uses a one-off MempoolRequest.

Desired Fix
Remove MempoolRequest and replace it with NetworkRequest.

Is your feature request related to a problem? Please describe.
In the document, https://www.rosetta-api.org/docs/models/AccountBalanceResponse.html suggests we put all unspent Coins owned by an account_identifier to coins field, but there may be a lot of unspent coins, so returning all unspent coins in one request may cause performance issues.

Describe the solution you'd like
It might be better if there is a separate pageable UTXO endpoint to get unspent coins for that account.

Describe alternatives you've considered

n/a

Additional context

n/a

I have a few questions/requests for clarification as to your specification

Amount.yaml

Amount is described as:

Amount is some Value of a Currency

Can it be changed to:

Amount is some Unit of Account

currency has legal implications, and strictly speaking, this is not entirely accurate for EVM chains as gas is the unit of account for EVM chains (typically) whereas ethereum

Account Identifier

currently reads:

• The account_identifier uniquely identifies an account within a network.

can it be expanded to fit a more approximate meaning of the word, as you can have a chain that uses the same derivation path in both instances but have assets in different addresses.

Also, can this be explicit in what it means as to what constitutes an "account"? Is it only EOA - Externally owned accounts only or can smart contract addresses be included with no distinction?

informative ref: eip1191.

example:

const hexChecksumChain = (name: string, coinType: number, chainId?: number) => ({
  coinType,	  coinType,
  decoder: decodeChecksummedHex,	  decoder: makeChecksummedHexDecoder(chainId),
  encoder: encodeChecksummedHex,	  encoder: makeChecksummedHexEncoder(chainId),
  name,	  name,
});	});

example ref: ensdomains/address-encoder/commit/5bf53b13fa014646ea28c9e5f937361dc9b40590

Network Identifer.yaml

The network_identifier specifies which network a particular object is associated with.

"If a blockchain has a specific chain-id or network identifier, it
should go in this field."

Can we also provide an (optional) direct link to a repository containing the genesis file? This would be the least ambiguous as to
** Informative ** ethereum-listss/chains

Additional references and sources can be made available. A Java SDK would be trivial, I just would like to not have to make awkward choices if possible, these are the ones just most apparent.

Thank you.

Describe the bug
The Operation Schema specification misspelt "NetowrkStatus" in the type field.

Additional context
https://github.com/coinbase/rosetta-specifications/blob/master/models/Operation.yaml#L45

Requiring that ConstructionDeriveResponse and SigningPayload contain Address instead of AccountIdentifier limits the ability to associate multiple keys with a given account (with a separate key for each SubAccount).

We should add an optional AccountIdentifier field to both of these objects that can be populated in lieu of Address. This ensures that existing implementations are not broken by this change without preventing new implementations from taking advantage of this increase expressivity.

Unreviewed commit(s) COMPARE was merged to master by patrick-ogrady.

Comment with appropriate number of 👍 to approve.

Describe the bug
This file could use some step-by-step instructions to improve contributions.

To Reproduce
Steps to reproduce the behavior:

• Read the file. Try to follow the directions.

Expected behavior

• Read the file. Easily follow the directions.

In some blockchains, funds only become accessible after some future block index. We should add a field on the operation model (or on the coin model) that allows an implementer to indicate this is the case (right now this usually happens in metadata).

One very important example of this is the lock on Bitcoin coinbase funds (which can't be spent for 100 blocks). See COINBASE_MATURITY in the Bitcoin protocol rules.

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Without block height, the returned balance does not make sense.

Describe the solution you'd like
A clear and concise description of what you want to happen.
add block height into /account/balance request/response, e.g., https://www.rosetta-api.org/docs/AccountApi.html

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
When pruning is enabled on a node, it is often useful to know what the oldest unpruned block is. In v1.3.1, there is no way to represent this.

Describe the solution you'd like
Add oldest_block_identifier to NetworkStatusResponse

Describe alternatives you've considered
Considered using genesis_block_identifier field in NetworkStatusResponse to represent last unpruned block, but this is a confusing misuse of available fields.

Describe the bug
Cannot generate grpc (.proto) definitions

Body" keys:"required"
Errors reading api.yaml
Plugin error: [file "api.proto" included an unresolvable reference to "api.NetworkIdentifierYaml"]

To Reproduce
Clone the rosetta specifications directory - only need to do once

git clone [email protected]:coinbase/rosetta-specifications.git
cd rosetta-specifications

Get gnostic, gnositc-grpc and gnostic-go-generator - only need to do once

go get -u github.com/googleapis/gnostic
go get -u github.com/googleapis/gnostic-grpc
go get -u github.com/googleapis/gnostic-go-generator

Try and generate the grpc definition

gnostic api.yaml --grpc-out=rosetta.proto

Expected behavior
A rosetta.proto file is created

Additional context
Detailed gist containing the log is here
I can be reached at https://johnwhitton.dev or [email protected]

The Construction API currently assumes there is at most one KeyPair associated with a given AccountIdentifier (this does not mean there can only be a single KeyPair associated with an AccountIdentifier as there can be multiple AccountIdentifiers with the same Address with different SubAccounts). This restriction does not prevent many stake-based multi-sig flows but does block "Bitcoin-style" multi-sig transactions.

We should find some way to support returning multiple PublicKeys for a given AccountIdentifier (likely just wrapping PublicKey with the associated AccountIdentifier) in /construction/metadata and /construction/payloads. We may also need to add a field to SigningPayload to indicate which PublicKey should be used to sign a particular payload (when it is possible to use multiple).

Sometimes, transaction construction requires signing a payload that is comprised of the signature of another payload (i.e. iterative transaction construction). Specifically, this would unblock blockchains that allow delegating "voting" operations to a separate key (but require a "proof of ownership" signature during construction from the new "voting" key). It is possible that some multi-sig constructions also require multiple phases.

I think this project could benefit from integration with OpenRPC which provides a base foundation for service discovery and tooling such as documentation/client generation/mock server for JSON-RPC akin to OpenAPI/Swagger.

Here is an example of an ethereum node with the OpenRPC playground, it gets the OpenRPC Document via calling the rpc.discover method:

https://playground.open-rpc.org/?schemaUrl=https://services.jade.builders/core-geth/mainnet/1.11.2

and an example of the raw document: https://github.com/etclabscore/ethereum-json-rpc-specification/blob/master/openrpc.json

Let me know how I can help.

• Add Coin Model for UTXO Tracking ( Identifier as string + CoinAction[create,spend])...do we need to create CoinIdentifier?)...optionally allow for returning Coins in /account/balance response: identifier + amount (#30)
• Optionally Report Syncing Status (#27) ... will need to clarify wording around what current_block_identifier is vs syncing_block_identifier... should also clarify that it is completely informational
• Unify TransactionIdentifierResponse for /construction/submit and /construction/hash (#29 )
• Use 500 for all non-200 (#29 )
• Update version to v.1.4.1 (#29)

Is your feature request related to a problem? Please describe.
The current error response only includes a code and a message. This makes it impossible to return any error context given that the message is supposed to explain the code.

Describe the solution you'd like
Add a metadata field to the error type that makes it possible to return error context. It may also be desirable to change message to type?

Is your feature request related to a problem? Please describe.
It is unclear if making an account balance request with an AccountIdentifier without a populated SubAccountIdentifier should return the balance of all SubAccountIdentifiers pertaining to an AccountIdentifier.

Describe the solution you'd like
Clearly state the balance returned on a request that does not include a SubAccountIdentifier should only include the balance that does not pertain to any SubAccountIdentifier.

Specific Example
In the case of a blockchain with staking, each address may have balances described by:

{
  "address": "addr"
}

{
  "address": "addr",
  "sub_account": {
    "address": "staked"
  }
}

The documentation should state that requests for the balance of {"address":"addr"} will not return the balance of {"address": "addr", "sub_account": {"address": "staked"}}.

I'm working for an exchange and have integrated a blockchain by using Rosetta. This project is really amazing and is well compatible with our current blockchain integration process. But there is a feature I want to request.

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

We will check the address that the customer input in the withdrawal process:

1. customer might input an invalid address by mistake, in which case, we should remind him/her to do re-check. For example, 1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM8 is a valid address but 1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM9 is not.
2. customer might input an address in the format which we don't support yet or are not ready to open to customers. For example, for Bitcoin, we support the withdrawal to P2PKH and P2SH address , but we don't support the withdrawal to P2WPKH and P2WSH address.

For the blockchain we have integrated via Rosetta, I used /account/balance to check if the address is valid or not; For invalid address, it would returninvalid account name. But I think it's just a workaround, and is not working for the case 2 above.

Describe the solution you'd like

I am wondering if Rosetta can add one more API, like /account/info:

1. for case 1, it returns "invalid account"
2. for case 2, it returns something like this:

{
 "account_identifier": {
  "address": "1JTxUeSwH5Ba2ib2UD6Whv5ZXB8RRjfRM8",
  "sub_account": {
   "address": "aabbcc",
   "metadata": {}
  },
  "metadata": {},
  "type": "P2PKH"
 }
}

The type field is not in the metadata for it's not optional.

Usually for paginated responses, a "total count" is available. Since there are offset and limit params, adding total_count to SearchTransactionsResponse would be helpful, especially when querying for address transactions.

Is your feature request related to a problem? Please describe.
When running rosetta-cli check, the only argument that developers ever provide (to override the default) is --lookup-balance-by-block=false. This argument has caused a lot of confusion and the specification should be modified so that this can be inferred automatically from an implementation.

Describe the solution you'd like
Add something like historical_balance_lookup to NetworkOptionsResponse so that we can remove this setting entirely from rosetta-cli.
https://github.com/coinbase/rosetta-specifications/blob/439b881859b0982bb6baf34a9666db1018d419f9/api.yaml#L615-L627

Describe alternatives you've considered
We already provide a lot of documentation around this flag but it is often overlooked during implementation as there are so many other factors on developers' minds.

These are currently listed only on a community blog post and as such end up being harder to find and non-authoritative.

These requirements should be listed either here or on the official spec website.

The rosetta-bitcoin and rosetta-ethereum set the call_methods and balance_exemptions to null. The spec mandates a type of array. It seems like the correct thing to do would be to set the fields to nullable in the spec or return empty arrays in the implementations. Alternatively it would be even better to make the fields optional, but that's a backwards compatibility issue.

Hello,

I am Ramil, CTO at ConsiderITDone Technology ([email protected])
I have filled and submitted Rosetta Grant form but haven't get any response.

Was it something wrong with my proposal?

Thank you

Describe the bug
This error was reported when I submitted a signed transaction.
{"code":17,"message":"malformed value","retriable":false}

This is request body
Oasis does not require sub_network_identifier

curl 'http://localhost:8080/construction/submit' -d '{
"network_identifier": {
"blockchain": "Oasis",
"network": "53852332637bacb61b91b6411ab4095168ba02a50be4c3f82448438826f23898"
},
"signed_transaction": "a6e54d42f3a0c25eab2eeff904e9ce5894a0a553f6dae46257346114a9114b3c9cb2a0d0766350148428d1cadc2f4425ef8611604a65e1a38999ed07647acc03"
}'

In some blockchains, the balance of an AccountIdentifier will increase each block because of block rewards (sometimes this causes a SubAccountIdentifier to decrease at the same time). Often times, there is no explicit operation that represents this balance change (as this would require creating an operation for every account in every block).

We should find a way to support "exempting" certain SubAccounts or Currencies from reconciliation requirements so that implementers that have this sort of abstraction can complete their Rosetta API implementation.

Describe the bug
There is a typo in the CONTRIBUTING.md file that breaks the code that hides the URLs list.

To Reproduce
Steps to reproduce the behavior:

• Open the file.
• Scroll to the end.
• See the mistake.

Expected behavior
The URLs list should not show.

Additional context
n/a

Bitcoin's BIP-340 Schnorr signature scheme is a secp256k1 curve variant not directly supported by Rosetta.

The primary outward distinction between the Ecdsa/Secp256k1 scheme and BIP-340 is the use of x-only 32-byte publicKeys and 64-byte ([R,s]) signatures.

BIP-340's underlying Sign/Verify scheme also internally encodes the signing keyPairs' signature and public point as its variants whose 'Y' coordinates are a quadratic residue ('even'). (see more here: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design)

Benefits

BIP-340 provides greater (provable) security than ECDSA/secp256k1-based schemes and offers signature non-malleability and linearity. Signing also makes use of "tagged hashes" to mitigate things like related-key attacks, which accordingly "...increases robustness in multi-user settings."

While this proposal to introduce BIP-340 does not include multisignature support, this would be a likely precondition to doing so. (e.g., #50)

Solution

Add the following to rosetta-specifications:

• ./models/CurveType.yaml - Secp256k1Bip340
• ./models/SignatureType.yaml - SchnorrBip340

Once approved and released, implement the following in rosetta-sdk-go including any relevant tests:

• ./keys/keys.go - Key Import & Generation
• ./keys/signer_bip340.go - Sign & Verify

It should be mentioned that the new CurveType is necessary due to BIP-340's requirement of 32-byte/x-only keys while the existing rosetta-sdk-go key interface extends no such ability under the existing Secp256k1 curve.

CurveType

rosetta-specifications

# CurveType.yaml

description: |
  CurveType is the type of cryptographic curve associated with a PublicKey.
  * secp256k1: SEC compressed - `33 bytes` (https://secg.org/sec1-v2.pdf#subsubsection.2.3.3)
+ * secp256k1_bip340: x-only - `32 bytes`  (implicitly even `Y` coord. Secp256k1 compressed keys may be repurposed by dropping the first byte. (https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#Public_Key_Generation))
  * secp256r1: SEC compressed - `33 bytes` (https://secg.org/sec1-v2.pdf#subsubsection.2.3.3)
  * edwards25519: `y (255-bits) || x-sign-bit (1-bit)` - `32 bytes` (https://ed25519.cr.yp.to/ed25519-20110926.pdf)
  * tweedle: 1st pk : Fq.t (32 bytes) || 2nd pk : Fq.t (32 bytes) (https://github.com/CodaProtocol/coda/blob/develop/rfcs/0038-rosetta-construction-api.md#marshal-keys)
  * pallas: `x (255 bits) || y-parity-bit (1-bit) - 32 bytes` (https://github.com/zcash/pasta)
type: string
enum:
  - secp256k1
+ - secp256k1_bip340
  - secp256r1
  - edwards25519
  - tweedle
  - pallas

rosetta-sdk-go Key Import

• Accept the import of any standard secp256k1 privateKey and drop the first byte (compression odd/even flag) of its associated publicKey per BIP-340 spec to extend backward compatibility.
  • This results in a 32-byte publicKey vs. secp256k1's 33-byte compressed publicKey.
  • No further tweaks need to be performed to an imported keyPair as the Sign/Verify scheme implicitly chooses the 'Y' coordinates that are a quadratic residue.

The above would be implemented in rosetta-sdk-go in the file ./keys/keys.go and add the import of the following package:

• "github.com/btcsuite/btcd/btcec/v2"

*note that github.com/btcsuite/btcd packages are already used by rosetta-sdk-go.

rosetta-sdk-go Key Generation

• Explicitly choose the keyPair whose public key has a Y value that is a quadratic residue by negating the newly-generated privateKey when its associated public key is found to be 'odd' in its compressed form.

The above would be implemented in rosetta-sdk-go in the file ./keys/keys.go and add the import of the following package:

• "github.com/btcsuite/btcd/btcec/v2"

*note that github.com/btcsuite/btcd packages are already used by rosetta-sdk-go.

References

• BIP-340 Design: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#design
• BIP-340 PublicKey Generation: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#public-key-generation
• BIP-340 PublicKey Conversion: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#public-key-conversion

SignatureType

rosetta-specifications

# SignatureType.yaml

description: |
  SignatureType is the type of a cryptographic signature.
  * ecdsa: `r (32-bytes) || s (32-bytes)` - `64 bytes`
  * ecdsa_recovery: `r (32-bytes) || s (32-bytes) || v (1-byte)` - `65 bytes`
  * ed25519: `R (32-byte) || s (32-bytes)` - `64 bytes`
  * schnorr_1: `r (32-bytes) || s (32-bytes)` - `64 bytes`  (schnorr signature implemented by Zilliqa where both `r` and `s` are scalars encoded as `32-bytes` values, most significant byte first.)
+ * schnorr_bip340: `r (32-bytes) || s (32-bytes)` - `64 bytes`  (sig = (bytes(R) || bytes((k + ed) mod n) where `r` is the `X` coordinate of a point `R` whose `Y` coordinate is even, most significant bytes first.)
  * schnorr_poseidon: `r (32-bytes) || s (32-bytes)` where s = Hash(1st pk || 2nd pk || r) - `64 bytes`  (schnorr signature w/ Poseidon hash function implemented by O(1) Labs where both `r` and `s` are scalars encoded as `32-bytes` values, least significant byte first. https://github.com/CodaProtocol/signer-reference/blob/master/schnorr.ml )
type: string
enum:
  - ecdsa
  - ecdsa_recovery
  - ed25519
  - schnorr_1
+ - schnorr_bip340
  - schnorr_poseidon

rosetta-sdk-go Sign & Verify

• Sign: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#default-signing
• Verify https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#verification

The above would be implemented in rosetta-sdk-go as the file ./keys/signer_bip340.go and make use of the following import packages:

• "github.com/btcsuite/btcd/btcec/v2"
• "github.com/btcsuite/btcd/btcec/v2/schnorr"

*note that github.com/btcsuite/btcd packages are already used by rosetta-sdk-go.

Backwards Compatible

Key Imports: Yes
Everything Else: n/a

Summary: Make "Operations" field on Transaction Model optional so we can efficiently return /search/transactions response with just the tx hashes instead of calling /block/transaction on EACH tx to get the operations data
AND
Make block_identifier optional in BlockResponse: https://www.rosetta-api.org/docs/models/BlockTransaction.html

Motivation
The recent addition of /search/transactions indexer api opened up a use case of getting "all txs by an address".
We currently enable this by storing all txs by address in a mongo database

"address": {
   id: "232323"
  "transactions": [ hash1, hash2 ]
}

Notice that we only store the hashes not the full transaction data. Now getting this data is easy.

POST /search/transactions
{
    ...
     "account_identifier": {
        "address": "addr_12312112112"
    }
}
Response:
{
    ....
    "transactions": [
        {
            "transaction_identifier": {
                "hash": "hash1",
            }
        },
        {
            "transaction_identifier": {
                "hash": "hash2"
            }
        }
    ]
}

However https://www.rosetta-api.org/docs/models/Transaction.html states that "operations" field is required in the response of transaction. Which means we will have to query /block/transaction by this hash for EVERY tx in our list. This could be thousands of query for some addresses.

Also sometimes we don't care about the operations value and just want to get the list of transaction hashes by account so its quite inefficient to return all the operations when not needed.

With the same logic https://www.rosetta-api.org/docs/models/BlockTransaction.html the "block_identifier" should be optional as returning this for each tx would require extra db calls

Proposal:
Make "Operations" field optional in https://www.rosetta-api.org/docs/models/Transaction.html
This doesn't break any implementations as they were already sending it anyways. And for the /search/transactions api we will omit sending it saving us thousands of extra api calls.
AND
Make block_identifier field optional in https://www.rosetta-api.org/docs/models/BlockTransaction.html

Unreviewed commit(s) COMPARE was merged to master by patrick-ogrady.

Comment with appropriate number of 👍 to approve.