Protocol 13 support #317
Merged
Protocol 13 support #317
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
abuiles
force-pushed
the
protocol-13
branch
3 times, most recently
from
6965206 to
dc13c20
Compare
vcarl
reviewed
Apr 13, 2020
tamirms
reviewed
Apr 13, 2020
tamirms
reviewed
Apr 13, 2020
ire-and-curses
approved these changes
Apr 13, 2020
abuiles
commented
Apr 13, 2020
| @@ -333,7 +333,8 @@ export namespace Operation { | |||
| interface AllowTrust extends BaseOperation<OperationType.AllowTrust> { | |||
| trustor: string; | |||
| assetCode: string; | |||
| authorize: boolean | undefined; | |||
| // this is a boolean or a number so that it can support protocol 12 or 13 | |||
| authorize: boolean | number | undefined; | |||
There was a problem hiding this comment.
@ire-and-curses @tamirms I'll actually do the same for this, add the breaking change, making it a number.
abuiles
added a commit
that referenced
this pull request
Apr 20, 2020
* Update XDR definitions. * Fix hash generation with v1 or v0 transactions. * Pass networkPassphrase. * Fix transaction envelope for TransactionV1Envelope. * Fix more transaction related tests. * Update type for allowTrust. * Fix test for authorize. * Build a TransactionV0. * Add comment on TS types.
Merged
abuiles
added a commit
that referenced
this pull request
Apr 27, 2020
This version brings protocol 13 support with backwards compatibility support for protocol 12. ### Add - Add `TransactionBuilder.buildFeeBumpTransaction` which makes it easy to create `FeeBumpTransaction` ([#321](#321)). - Adds a feature flag which allow consumers of this library to create V1 (protocol 13) transactions using the `TransactionBuilder` ([#321](#321)). - Add support for [CAP0027](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0027.md): First-class multiplexed accounts ([#325](#325)). - Add `Keypair.xdrMuxedAccount` which creates a new `xdr.MuxedAccount`([#325](#325)). - Add `FeeBumpTransaction` which makes it easy to work with fee bump transactions ([#328](#328)). - Add `TransactionBuilder.fromXDR` which receives an xdr envelope and return a `Transaction` or `FeeBumpTransaction` ([#328](#328)). ### Update - Update XDR definitions with protocol 13 ([#317](#317)). - Extend `Transaction` to work with `TransactionV1Envelope` and `TransactionV0Envelope` ([#317](#317)). - Add backward compatibility support for [CAP0018](https://github.com/stellar/stellar-protocol/blob/f01c9354aaab1e8ca97a25cf888829749cadf36a/core/cap-0018.md) ([#317](#317)). - Update operations builder to support multiplexed accounts ([#337](#337)). This allows you to specify an `M` account as the destination or source: ``` var destination = 'MAAAAAAAAAAAAAB7BQ2L7E5NBWMXDUCMZSIPOBKRDSBYVLMXGSSKF6YNPIB7Y77ITLVL6'; var amount = '1000.0000000'; var asset = new StellarBase.Asset( 'USDUSD', 'GDGU5OAPHNPU5UCLE5RDJHG7PXZFQYWKCFOEXSXNMR6KRQRI5T6XXCD7' ); var source = 'MAAAAAAAAAAAAAB7BQ2L7E5NBWMXDUCMZSIPOBKRDSBYVLMXGSSKF6YNPIB7Y77ITLVL6'; StellarBase.Operation.payment({ destination, asset, amount, source }); ``` **To use multiplexed accounts you need an instance of Stellar running on Protocol 13 or higher** ### Breaking changes - `Transaction.toEnvelope()` returns a protocol 13 `xdr.TransactionEnvelope` which is an `xdr.Union` ([#317](#317)). If you have code that looks like this `transaction.toEnvelope().tx` you have two options: - You can grab the value wrapped by the union, calling `value()` like `transaction.toEnvelope().value().tx`. - You can check which is the discriminant by using `switch()` and then call `v0()`, `v1()`, or `feeBump()`. - The return value from `Transaction.fee` changed from `number` to `string`. This brings support for `Int64` values ([#321](#321)). - The const `BASE_FEE` changed from `number` to `string` ([#321](#321)). - The option `fee` passed to `new TransactionBuilder({fee: ..})` changed from `number` to `string` ([#321](#321)). - The following fields, which were previously an `xdr.AccountID` are now a `xdr.MuxedAccount` ([#325](#325)): - `PaymentOp.destination` - `PathPaymentStrictReceiveOp.destination` - `PathPaymentStrictSendOp.destination` - `Operation.sourceAccount` - `Operation.destination` (for `ACCOUNT_MERGE`) - `Transaction.sourceAccount` - `FeeBumpTransaction.feeSource` You can get the string representation by calling `StrKey.encodeMuxedAccount` which will return a `G..` or `M..` account. - Remove the following deprecated functions ([#331](#331)): - `Operation.manageOffer` - `Operation.createPassiveOffer` - `Operation.pathPayment` - `Keypair.fromBase58Seed` - Remove the `Network` class ([#331](#331)). - Remove `vendor/base58.js` ([#331](#331)).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Add protocol 13 support with backwards compatibility support for protocol 12.
Why
In order to provide a seamless transition between protocol 12 and 13, we need to release a new version of the SDK that can read and generate transactions which will work in both protocols.
This pull request:
Transactionto work withTransactionV1EnvelopeandTransactionV0Envelope.TransactionEnvelopewhich can be read by protocol 12 or protocol 13.TransactionEnvelopegenerated by protocol 12 or protocol 13.Transactionclass which offers an abstraction aroundxdr.Transactiondoesn't supportFeeBumpTransactionyet, however, consumers of this library can create and read fee bump transactions usingxdr.FeeBumpTransaction.Fix #320
Breaking changes
xdr.TransactionEnvelopeortransaction.toEnvelope()then there are breaking changes and you'll have to update your code to match the new API aroundxdr.TransactionEnvelope.