libra_client 0.1.3
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +7 -0
- data/.gitignore +14 -0
- data/.travis.yml +7 -0
- data/CODE_OF_CONDUCT.md +74 -0
- data/Gemfile +4 -0
- data/Gemfile.lock +51 -0
- data/LICENSE.txt +21 -0
- data/README.md +57 -0
- data/Rakefile +10 -0
- data/bin/console +16 -0
- data/bin/setup +8 -0
- data/gen_proto.sh +2 -0
- data/lib/libra/access_path.rb +51 -0
- data/lib/libra/account_address.rb +29 -0
- data/lib/libra/account_config.rb +57 -0
- data/lib/libra/account_resource.rb +38 -0
- data/lib/libra/mnemonic.rb +147 -0
- data/lib/libra/version.rb +3 -0
- data/lib/libra_client.rb +173 -0
- data/libra_client.gemspec +49 -0
- data/libra_client.sublime-project +16 -0
- data/proto-lib/access_path_pb.rb +17 -0
- data/proto-lib/account_state_blob_pb.rb +23 -0
- data/proto-lib/admission_control_pb.rb +37 -0
- data/proto-lib/admission_control_services_pb.rb +37 -0
- data/proto-lib/events_pb.rb +35 -0
- data/proto-lib/get_with_proof_pb.rb +88 -0
- data/proto-lib/ledger_info_pb.rb +31 -0
- data/proto-lib/mempool_status_pb.rb +21 -0
- data/proto-lib/proof_pb.rb +41 -0
- data/proto-lib/transaction_info_pb.rb +19 -0
- data/proto-lib/transaction_pb.rb +102 -0
- data/proto-lib/validator_change_pb.rb +19 -0
- data/proto-lib/vm_errors_pb.rb +215 -0
- data/protos/access_path.proto +11 -0
- data/protos/account_state_blob.proto +16 -0
- data/protos/admission_control.proto +76 -0
- data/protos/events.proto +38 -0
- data/protos/get_with_proof.proto +310 -0
- data/protos/ledger_info.proto +82 -0
- data/protos/mempool_status.proto +21 -0
- data/protos/proof.proto +72 -0
- data/protos/transaction.proto +170 -0
- data/protos/transaction_info.proto +26 -0
- data/protos/validator_change.proto +27 -0
- data/protos/vm_errors.proto +276 -0
- metadata +191 -0
@@ -0,0 +1,16 @@
|
|
1
|
+
// Copyright (c) The Libra Core Contributors
|
2
|
+
// SPDX-License-Identifier: Apache-2.0
|
3
|
+
|
4
|
+
syntax = "proto3";
|
5
|
+
|
6
|
+
package types;
|
7
|
+
|
8
|
+
import "proof.proto";
|
9
|
+
|
10
|
+
message AccountStateBlob { bytes blob = 1; }
|
11
|
+
|
12
|
+
message AccountStateWithProof {
|
13
|
+
uint64 version = 1;
|
14
|
+
AccountStateBlob blob = 2;
|
15
|
+
AccountStateProof proof = 3;
|
16
|
+
}
|
@@ -0,0 +1,76 @@
|
|
1
|
+
// Copyright (c) The Libra Core Contributors
|
2
|
+
// SPDX-License-Identifier: Apache-2.0
|
3
|
+
|
4
|
+
syntax = "proto3";
|
5
|
+
|
6
|
+
package admission_control;
|
7
|
+
|
8
|
+
import "get_with_proof.proto";
|
9
|
+
import "transaction.proto";
|
10
|
+
import "proof.proto";
|
11
|
+
import "ledger_info.proto";
|
12
|
+
import "vm_errors.proto";
|
13
|
+
import "mempool_status.proto";
|
14
|
+
|
15
|
+
// -----------------------------------------------------------------------------
|
16
|
+
// ---------------- Submit transaction
|
17
|
+
// -----------------------------------------------------------------------------
|
18
|
+
// The request for transaction submission.
|
19
|
+
message SubmitTransactionRequest {
|
20
|
+
// Transaction signed by wallet.
|
21
|
+
types.SignedTransaction signed_txn = 1;
|
22
|
+
}
|
23
|
+
|
24
|
+
// Additional statuses that are possible from admission control in addition
|
25
|
+
// to VM statuses.
|
26
|
+
enum AdmissionControlStatus {
|
27
|
+
Accepted = 0;
|
28
|
+
Blacklisted = 1;
|
29
|
+
Rejected = 2;
|
30
|
+
}
|
31
|
+
|
32
|
+
// The response for transaction submission.
|
33
|
+
//
|
34
|
+
// How does a client know if their transaction was included?
|
35
|
+
// A response from the transaction submission only means that the transaction
|
36
|
+
// was successfully added to mempool, but not that it is guaranteed to be
|
37
|
+
// included in the chain. Each transaction should include an expiration time in
|
38
|
+
// the signed transaction. Let's call this T0. As a client, I submit my
|
39
|
+
// transaction to a validator. I now need to poll for the transaction I
|
40
|
+
// submitted. I can use the query that takes my account and sequence number. If
|
41
|
+
// I receive back that the transaction is completed, I will verify the proofs to
|
42
|
+
// ensure that this is the transaction I expected. If I receive a response that
|
43
|
+
// my transaction is not yet completed, I must check the latest timestamp in the
|
44
|
+
// ledgerInfo that I receive back from the query. If this time is greater than
|
45
|
+
// T0, I can be certain that my transaction will never be included. If this
|
46
|
+
// time is less than T0, I need to continue polling.
|
47
|
+
message SubmitTransactionResponse {
|
48
|
+
// The status of a transaction submission can either be a VM status, or
|
49
|
+
// some other admission control/mempool specific status e.g. Blacklisted.
|
50
|
+
oneof status {
|
51
|
+
types.VMStatus vm_status = 1;
|
52
|
+
AdmissionControlStatus ac_status = 2;
|
53
|
+
mempool.MempoolAddTransactionStatus mempool_status = 3;
|
54
|
+
}
|
55
|
+
// Public key(id) of the validator that processed this transaction
|
56
|
+
bytes validator_id = 4;
|
57
|
+
}
|
58
|
+
|
59
|
+
// -----------------------------------------------------------------------------
|
60
|
+
// ---------------- Service definition
|
61
|
+
// -----------------------------------------------------------------------------
|
62
|
+
service AdmissionControl {
|
63
|
+
// Public API to submit transaction to a validator.
|
64
|
+
rpc SubmitTransaction(SubmitTransactionRequest)
|
65
|
+
returns (SubmitTransactionResponse) {}
|
66
|
+
|
67
|
+
// This API is used to update the client to the latest ledger version and
|
68
|
+
// optionally also request 1..n other pieces of data. This allows for batch
|
69
|
+
// queries. All queries return proofs that a client should check to validate
|
70
|
+
// the data. Note that if a client only wishes to update to the latest
|
71
|
+
// LedgerInfo and receive the proof of this latest version, they can simply
|
72
|
+
// omit the requested_items (or pass an empty list)
|
73
|
+
rpc UpdateToLatestLedger(
|
74
|
+
types.UpdateToLatestLedgerRequest)
|
75
|
+
returns (types.UpdateToLatestLedgerResponse) {}
|
76
|
+
}
|
data/protos/events.proto
ADDED
@@ -0,0 +1,38 @@
|
|
1
|
+
// Copyright (c) The Libra Core Contributors
|
2
|
+
// SPDX-License-Identifier: Apache-2.0
|
3
|
+
|
4
|
+
// This file contains proto definitions related to events. Events are emitted
|
5
|
+
// by smart contract execution. These could include events such as received
|
6
|
+
// transactions, sent transactions, etc.
|
7
|
+
|
8
|
+
syntax = "proto3";
|
9
|
+
|
10
|
+
package types;
|
11
|
+
|
12
|
+
import "access_path.proto";
|
13
|
+
import "proof.proto";
|
14
|
+
|
15
|
+
// An event emitted from a smart contract
|
16
|
+
message Event {
|
17
|
+
AccessPath access_path = 1;
|
18
|
+
uint64 sequence_number = 2;
|
19
|
+
bytes event_data = 3;
|
20
|
+
}
|
21
|
+
|
22
|
+
// An event along with the proof for the event
|
23
|
+
message EventWithProof {
|
24
|
+
uint64 transaction_version = 1;
|
25
|
+
uint64 event_index = 2;
|
26
|
+
Event event = 3;
|
27
|
+
EventProof proof = 4;
|
28
|
+
}
|
29
|
+
|
30
|
+
// A list of events.
|
31
|
+
message EventsList {
|
32
|
+
repeated Event events = 1;
|
33
|
+
}
|
34
|
+
|
35
|
+
// A list of EventList's, each representing all events for a transaction.
|
36
|
+
message EventsForVersions {
|
37
|
+
repeated EventsList events_for_version = 1;
|
38
|
+
}
|
@@ -0,0 +1,310 @@
|
|
1
|
+
// Copyright (c) The Libra Core Contributors
|
2
|
+
// SPDX-License-Identifier: Apache-2.0
|
3
|
+
|
4
|
+
// This file contains proto definitions for performing queries and getting back
|
5
|
+
// results with proofs. This is the interface for a client to query data from
|
6
|
+
// the system. Every query result must include proof so that a client can be
|
7
|
+
// certain that the data returned is valid. A client must verify this proof to
|
8
|
+
// ensure that a node isn't lying to them.
|
9
|
+
|
10
|
+
// How to verify the response as a client:
|
11
|
+
// (Note that every response comes in the form of GetWithProofResponse which
|
12
|
+
// wraps the inner response elements that correspond to the specific request
|
13
|
+
// types. Below we will assume a single request/response type. The
|
14
|
+
// verification can be extended as needed for multiple types. Also note that we
|
15
|
+
// will use the following notation: resp = GetWithProofResponse and req =
|
16
|
+
// GetWithProofRequest). Also note that the following will be considered
|
17
|
+
// equivalent for brevity: req.requested_items.get_account_state_request ==
|
18
|
+
// req.get_account_state_request And, resp.values.get_account_state_response ==
|
19
|
+
// resp.get_account_state_response
|
20
|
+
//
|
21
|
+
// GetAccountStateResponse:
|
22
|
+
// - let state_req = req.requested_items.get_account_state_request;
|
23
|
+
// - let state_resp = resp.values.get_account_state_response;
|
24
|
+
// - Verify that:
|
25
|
+
// - state_req.access_path == state_resp.access_path
|
26
|
+
// - This ensures that the server is responding with the correct access
|
27
|
+
// path
|
28
|
+
// - let state_data_hash = Hash(state_resp.value);
|
29
|
+
// - let state_proof = resp.values.proof.state_proof_value.sparse_merkle_proof;
|
30
|
+
// - Validate state_proof using state_data_hash as the leaf
|
31
|
+
// - When verifying the state tree, use:
|
32
|
+
// state_root_hash = resp.values.transaction_info.state_root_hash
|
33
|
+
// - Validate accumulator using resp.values.transaction_info as the leaf
|
34
|
+
// - When verifying the accumulator, use:
|
35
|
+
// root_hash =
|
36
|
+
// resp.ledger_info_with_sigs.ledger_info.ledger_info.txn_root_hash;
|
37
|
+
// - Validate that the transaction root hash submitted in
|
38
|
+
// req.known_value.node_value.txn_root_hash
|
39
|
+
// exists in the proof for accumulator and that the proof is valid with
|
40
|
+
// this hash
|
41
|
+
// - Validate ledger info
|
42
|
+
// - let ledger_info_hash =
|
43
|
+
// Hash(resp.ledger_info_with_sigs.ledger_info.ledger_info);
|
44
|
+
// - Verify signatures from resp.ledger_info_with_sigs.signatures are
|
45
|
+
// signing
|
46
|
+
// ledger_info_hash and that there are >2/3 nodes signing this
|
47
|
+
// correctly
|
48
|
+
// - Validate that the timestamp is relatively recent in
|
49
|
+
// resp.ledger_info_with_sigs.ledger_info.timestamp
|
50
|
+
//
|
51
|
+
//
|
52
|
+
// GetAccountTransactionBySequenceNumberResponse:
|
53
|
+
// - Note that other than type completed_transaction, there will be no proof
|
54
|
+
// returned
|
55
|
+
// since the transaction has not yet been committed. To ensure that a
|
56
|
+
// validator is telling the truth about it not being committed yet, a
|
57
|
+
// client should query for their account state and verify that their
|
58
|
+
// current sequence number is less than what they are searching for with
|
59
|
+
// GetAccountTransactionBySequenceNumberResponse
|
60
|
+
// - let txn =
|
61
|
+
// resp.get_account_transaction_by_sequence_number_response.transaction.committed_transaction;
|
62
|
+
// - let txn_hash = Hash(txn);
|
63
|
+
// - Verify that resp.proof.transaction_info.signed_transaction_hash == txn_hash
|
64
|
+
// - Validate accumulator using resp.proof.transaction_info as the leaf
|
65
|
+
// - When verifying the accumulator, use:
|
66
|
+
// root_hash =
|
67
|
+
// resp.ledger_info_with_sigs.ledger_info.ledger_info.txn_root_hash;
|
68
|
+
// - Validate that the transaction root hash submitted in
|
69
|
+
// req.known_value.node_value.txn_root_hash
|
70
|
+
// exists in the proof for accumulator and that the proof is valid with
|
71
|
+
// this hash
|
72
|
+
// - Validate ledger info
|
73
|
+
// - let ledger_info_hash =
|
74
|
+
// Hash(resp.ledger_info_with_sigs.ledger_info.ledger_info);
|
75
|
+
// - Verify signatures from resp.ledger_info_with_sigs.signatures are
|
76
|
+
// signing
|
77
|
+
// ledger_info_hash and that there are >2/3 nodes signing this
|
78
|
+
// correctly
|
79
|
+
// - Validate that the timestamp is relatively recent in
|
80
|
+
// resp.ledger_info_with_sigs.ledger_info.timestamp
|
81
|
+
//
|
82
|
+
//
|
83
|
+
// GetTransactionsResponse:
|
84
|
+
// - for txn in resp.get_transactions_response.transactions:
|
85
|
+
// - let txn = txn.committed_transaction;
|
86
|
+
// - let txn_hash = Hash(txn);
|
87
|
+
// - Verify that txn.proof.transaction_info.signed_transaction_hash ==
|
88
|
+
// txn_hash
|
89
|
+
// - Validate accumulator using txn.proof.transaction_info as the leaf
|
90
|
+
// - When verifying the accumulator, use:
|
91
|
+
// root_hash =
|
92
|
+
// resp.ledger_info_with_sigs.ledger_info.ledger_info.txn_root_hash;
|
93
|
+
// - Verify that transactions are sequential and none are missing
|
94
|
+
// - Validate ledger info
|
95
|
+
// - let ledger_info_hash =
|
96
|
+
// Hash(resp.ledger_info_with_sigs.ledger_info.ledger_info);
|
97
|
+
// - Verify signatures from resp.ledger_info_with_sigs.signatures are
|
98
|
+
// signing
|
99
|
+
// ledger_info_hash and that there are >2/3 nodes signing this
|
100
|
+
// correctly
|
101
|
+
// - Validate that the timestamp is relatively recent in
|
102
|
+
// resp.ledger_info_with_sigs.ledger_info.timestamp
|
103
|
+
// - If the number of transactions returned is less than limit for an ascending
|
104
|
+
// query
|
105
|
+
// or if the requested offset > current version for a descending query,
|
106
|
+
// the client should verify that the timestamp in ledger info is relatively
|
107
|
+
// recent to determine if it is likely that all transactions available were
|
108
|
+
// returned
|
109
|
+
syntax = "proto3";
|
110
|
+
|
111
|
+
package types;
|
112
|
+
|
113
|
+
import "access_path.proto";
|
114
|
+
import "account_state_blob.proto";
|
115
|
+
import "events.proto";
|
116
|
+
import "ledger_info.proto";
|
117
|
+
import "transaction.proto";
|
118
|
+
import "validator_change.proto";
|
119
|
+
|
120
|
+
// -----------------------------------------------------------------------------
|
121
|
+
// ---------------- Update to latest ledger request
|
122
|
+
// -----------------------------------------------------------------------------
|
123
|
+
|
124
|
+
// This API is used to update the client to the latest ledger version and
|
125
|
+
// optionally also request 1..n other pieces of data. This allows for batch
|
126
|
+
// queries. All queries return proofs that a client should check to validate
|
127
|
+
// the data.
|
128
|
+
//
|
129
|
+
// Note that if a client only wishes to update to the latest LedgerInfo and
|
130
|
+
// receive the proof that this latest ledger extends the client_known_version
|
131
|
+
// ledger the client had, they can simply set the requested_items to an empty
|
132
|
+
// list.
|
133
|
+
message UpdateToLatestLedgerRequest {
|
134
|
+
// This is the version the client already trusts. Usually the client should
|
135
|
+
// set this to the version it obtained the last time it synced with the
|
136
|
+
// chain. If this is the first time ever the client sends a request, it must
|
137
|
+
// use the waypoint hard-coded in its software.
|
138
|
+
uint64 client_known_version = 1;
|
139
|
+
|
140
|
+
// The items for which we are requesting data in this API call.
|
141
|
+
repeated RequestItem requested_items = 2;
|
142
|
+
}
|
143
|
+
|
144
|
+
message RequestItem {
|
145
|
+
oneof requested_items {
|
146
|
+
GetAccountStateRequest get_account_state_request = 1;
|
147
|
+
GetAccountTransactionBySequenceNumberRequest
|
148
|
+
get_account_transaction_by_sequence_number_request = 2;
|
149
|
+
GetEventsByEventAccessPathRequest get_events_by_event_access_path_request =
|
150
|
+
3;
|
151
|
+
GetTransactionsRequest get_transactions_request = 4;
|
152
|
+
}
|
153
|
+
}
|
154
|
+
|
155
|
+
// -----------------------------------------------------------------------------
|
156
|
+
// ---------------- Update to latest ledger response
|
157
|
+
// -----------------------------------------------------------------------------
|
158
|
+
|
159
|
+
// Response from getting latest ledger
|
160
|
+
message UpdateToLatestLedgerResponse {
|
161
|
+
// Responses to the queries posed by the requests. The proofs generated will
|
162
|
+
// be relative to the version of the latest ledger provided below.
|
163
|
+
repeated ResponseItem response_items = 1;
|
164
|
+
|
165
|
+
// The latest ledger info this node has. It will come with at least 2f+1
|
166
|
+
// validator signatures as well as a proof that shows the latest ledger
|
167
|
+
// extends the old ledger the client had.
|
168
|
+
LedgerInfoWithSignatures ledger_info_with_sigs = 2;
|
169
|
+
|
170
|
+
// Validator change events from what the client last knew. This is used to
|
171
|
+
// inform the client of validator changes from the client's last known version
|
172
|
+
// until the current version
|
173
|
+
repeated ValidatorChangeEventWithProof validator_change_events = 3;
|
174
|
+
}
|
175
|
+
|
176
|
+
// Individual response items to the queries posed by the requests
|
177
|
+
message ResponseItem {
|
178
|
+
oneof response_items {
|
179
|
+
GetAccountStateResponse get_account_state_response = 3;
|
180
|
+
GetAccountTransactionBySequenceNumberResponse
|
181
|
+
get_account_transaction_by_sequence_number_response = 4;
|
182
|
+
GetEventsByEventAccessPathResponse get_events_by_event_access_path_response = 5;
|
183
|
+
GetTransactionsResponse get_transactions_response = 6;
|
184
|
+
}
|
185
|
+
}
|
186
|
+
|
187
|
+
// -----------------------------------------------------------------------------
|
188
|
+
// ---------------- Get account state (balance, sequence number, etc.)
|
189
|
+
// -----------------------------------------------------------------------------
|
190
|
+
|
191
|
+
// Gets latest state for an account.
|
192
|
+
message GetAccountStateRequest {
|
193
|
+
// Account for which we are fetching the state.
|
194
|
+
bytes address = 1;
|
195
|
+
}
|
196
|
+
|
197
|
+
// State information returned by a get account state query.
|
198
|
+
message GetAccountStateResponse {
|
199
|
+
// Blob value representing the account state together with proof the client
|
200
|
+
// can utilize to verify it.
|
201
|
+
AccountStateWithProof account_state_with_proof = 1;
|
202
|
+
}
|
203
|
+
|
204
|
+
// -----------------------------------------------------------------------------
|
205
|
+
// ---------------- Get single transaction by account + sequence number
|
206
|
+
// -----------------------------------------------------------------------------
|
207
|
+
// Get transactions that altered an account - this includes both sent and
|
208
|
+
// received. A user of this should check that the data returned matches what
|
209
|
+
// they expect. As an example, a potential attack vector would be something
|
210
|
+
// like the following: Alice is buying an apple from Bob. Alice's phone signs a
|
211
|
+
// transaction X with sequence number N that pays coins to Bob. Alice transmits
|
212
|
+
// this signature to Bob's payment terminal which then submits the transaction
|
213
|
+
// and checks its status to see if Alice can be given the apple. However, as Bob
|
214
|
+
// is doing this Alice constructs a second transaction X' also with sequence
|
215
|
+
// number N. Alice gets that transaction inserted in the blockchain. If Bob
|
216
|
+
// isn't thoughtful about how he uses this API he may assume that if he asks for
|
217
|
+
// the N'th transaction on Alice's account that when the API returns that this
|
218
|
+
// means the transaction has gone through. The point here is that one should be
|
219
|
+
// careful in reading too much into "transaction X is on the chain" and focus on
|
220
|
+
// the logs, which tell you what the transaction did.
|
221
|
+
//
|
222
|
+
// If a client submitted a transaction, they should also verify that the hash of
|
223
|
+
// the returned transaction matches what they submitted. As an example, if a
|
224
|
+
// client has two wallets that share the same account, they may both submit a
|
225
|
+
// transaction at the same sequence number and only one will be committed. A
|
226
|
+
// client should never assume that if they receive the response that this
|
227
|
+
// transaction was included that it means that this is definitely the
|
228
|
+
// transaction that was submitted. They should check that the hash matches what
|
229
|
+
// they sent
|
230
|
+
message GetAccountTransactionBySequenceNumberRequest {
|
231
|
+
// Account for which to query transactions
|
232
|
+
bytes account = 1;
|
233
|
+
|
234
|
+
uint64 sequence_number = 2;
|
235
|
+
|
236
|
+
// Set to true to fetch events for the transaction at this version
|
237
|
+
bool fetch_events = 3;
|
238
|
+
}
|
239
|
+
|
240
|
+
// Transaction information for transactions requested by
|
241
|
+
// GetAccountTransactionsRequest
|
242
|
+
message GetAccountTransactionBySequenceNumberResponse {
|
243
|
+
// When the transaction requested is committed, return the committed
|
244
|
+
// transaction with proof.
|
245
|
+
SignedTransactionWithProof signed_transaction_with_proof = 2;
|
246
|
+
// When the transaction requested is not committed, we give a proof that
|
247
|
+
// shows the current sequence number is smaller than what would have been if
|
248
|
+
// the transaction was committed.
|
249
|
+
AccountStateWithProof proof_of_current_sequence_number = 3;
|
250
|
+
}
|
251
|
+
|
252
|
+
// -----------------------------------------------------------------------------
|
253
|
+
// ---------------- Get events by event access path
|
254
|
+
// -----------------------------------------------------------------------------
|
255
|
+
|
256
|
+
// Get events that exist on an event access path. In the current world,
|
257
|
+
// a user may specify events that were received, events that were sent, or any
|
258
|
+
// event that modifies their account
|
259
|
+
message GetEventsByEventAccessPathRequest {
|
260
|
+
AccessPath access_path = 1;
|
261
|
+
|
262
|
+
// The sequence number of the event to start with for this query. Use a
|
263
|
+
// sequence number of MAX_INT to represent the latest.
|
264
|
+
uint64 start_event_seq_num = 2;
|
265
|
+
|
266
|
+
// If ascending is true this query will return up to `limit` events that were
|
267
|
+
// emitted after `start_event_seq_num`. Otherwise it will return up to `limit`
|
268
|
+
// events before the offset. Both cases are inclusive.
|
269
|
+
bool ascending = 3;
|
270
|
+
|
271
|
+
// Limit number of results
|
272
|
+
uint64 limit = 4;
|
273
|
+
}
|
274
|
+
|
275
|
+
message GetEventsByEventAccessPathResponse {
|
276
|
+
// Returns an event and proof of each of the events in the request. The first
|
277
|
+
// element of proofs will be the closest to `start_event_seq_num`.
|
278
|
+
repeated EventWithProof events_with_proof = 1;
|
279
|
+
|
280
|
+
// If the number of events returned is less than `limit` for an ascending
|
281
|
+
// query or if start_event_seq_num > the latest seq_num for a descending
|
282
|
+
// query, returns the state of the account containing the given access path
|
283
|
+
// in the latest state. This allows the client to verify that there are in
|
284
|
+
// fact no extra events.
|
285
|
+
//
|
286
|
+
// The LedgerInfoWithSignatures which is on the main
|
287
|
+
// UpdateToLatestLedgerResponse can be used to validate this.
|
288
|
+
AccountStateWithProof proof_of_latest_event = 2;
|
289
|
+
}
|
290
|
+
|
291
|
+
// -----------------------------------------------------------------------------
|
292
|
+
// ---------------- Get transactions
|
293
|
+
// -----------------------------------------------------------------------------
|
294
|
+
|
295
|
+
// Get up to limit transactions starting from start_version.
|
296
|
+
message GetTransactionsRequest {
|
297
|
+
// The version of the transaction to start with for this query. Use a version
|
298
|
+
// of MAX_INT to represent the latest.
|
299
|
+
uint64 start_version = 1;
|
300
|
+
|
301
|
+
// Limit number of results
|
302
|
+
uint64 limit = 2;
|
303
|
+
|
304
|
+
// Set to true to fetch events for the transaction at each version
|
305
|
+
bool fetch_events = 3;
|
306
|
+
}
|
307
|
+
|
308
|
+
message GetTransactionsResponse {
|
309
|
+
TransactionListWithProof txn_list_with_proof = 1;
|
310
|
+
}
|