Repository navigation
Conversation
Bump XDR_COMMIT to stellar-xdr 84cd9fa6 (PR stellar#318, unmerged) and enable the CAP_0087_ML_DSA feature gate, adding ContractCostTypes 86-94 for ML-DSA verifying-key/signature decoding and signature verification. Regeneration is mandatory rather than cosmetic: ContractCostTypeView.Value() matches an exhaustive whitelist of cost types, so it would reject 86-94 on any protocol-30 config-setting read. Unrelated upstream drift in the pinned range widens the contract-spec name fields to SC_SPEC_TYPE_NAME_LIMIT (1024) and retypes ScSpecEventV0.name from SCSymbol to a bounded string; no in-repo consumer references either. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Adds the SC_ADDRESS_TYPE_MUXED_CONTRACT arm of SCAddress. Also picks up the widened contract spec name limits from upstream.
Adds the W... muxed contract strkey (vectors from rs-stellar-strkey@80085faa) and handles the new ScAddress arm in String() and Equals().
|
|
||
| const SC_SPEC_DOC_LIMIT = 1024; | ||
|
|
||
| const SC_SPEC_TYPE_NAME_LIMIT = 1024; |
There was a problem hiding this comment.
I know it's not super related to this change but this seems unnecessarily large, no?
There was a problem hiding this comment.
I'll let @leighmcculloch comment on this.
There was a problem hiding this comment.
Agreed, it's pretty large. The value is really just their so that most XDR parsers will exit earlier on attempts by a malicious wasm to abuse tools. The value doesn't need to be any smaller to serve that purpose. And the value isn't trying to enforce any best practice like short-names-are-better.
The reason for the change now is that starting in v30 contract spec generation and processing will go through an intermediary step where their names will contain fully qualified Rust type names like ::mycontract::storage::types::MyWonderfulType and then will be transformed down into unique short names like MyWonderfulType.
Discussion about that here:
There was a problem hiding this comment.
Even though the final form is ideally not much longer than it is today, we need the additional space for the intermediary step. We could have a second set of XDR types just for that intermediary form, but I don't think it's worth it.
Match stellar-core stellar#5472's protocol-curr/xdr. Only CAP-0087 ifdef'd cost types differ from 01741cb6, and they stay disabled.
Contract balances aren't derivable from contractData, so C... holders were already skipped; W... addresses are contracts too.
A CAP-0084 muxed contract destination is recorded on contract_credited the way account_muxed/account_muxed_id record a muxed account.
Regenerate from stellar-xdr@ee040cd6 so ContractCostType 86-94 (ML-DSA) decode; ContractCostTypeView.Value() rejects unknown cost types in protocol-30 config settings.
|
Closing in favor of #6015, which now regenerates from stellar-xdr For the record, this regeneration only adds names: no XDR field has type |
Changes
XDR_FEATURESnow carriesCAP_0084_MUXED_CONTRACT,CAP_0087_ML_DSA; XDR regenerated from stellar-xdr@ee040cd6(account creation with horizon api #318 merged), addingContractCostType86-94. Required:ContractCostTypeView.Value()rejects unknown cost types.Stacked on #6015 (CAP-0084); shows its commits until it merges.
Upstream: stellar/stellar-xdr#318, stellar/stellar-core#5455 · Downstream: stellar-horizon, stellar-rpc