chore: update miden dependencies#2023
Conversation
juan518munoz
force-pushed
the
jmunoz-update-miden-deps
branch
from
16b5e9d to
a05c730
Compare
| note_id BLOB NOT NULL, | ||
| note_commitment BLOB NOT NULL, | ||
| note_type INTEGER NOT NULL, -- 1-Public (0b01), 2-Private (0b10), 3-Encrypted (0b11) | ||
| note_type INTEGER NOT NULL, -- 0-Private, 1-Public |
There was a problem hiding this comment.
Encrypted variant removed in 0xMiden/protocol#2315
Note that this change only works for newly created databases, as it's not a new, proper migration, but rather a modification to an already existing one (thus does not apply to existing DBs)
There was a problem hiding this comment.
Is this comment correct though? The PR you linked still has them as 1 and 2, https://github.com/0xMiden/protocol/pull/2315/changes#diff-c3b6ee362a233a6ad5b487e48cd19fb6ca264834b8f015e2daa72a1180d6c32fR16-R17
There was a problem hiding this comment.
Yes, it doesn't look correct. We sbhould just remove the Encrypted one.
There was a problem hiding this comment.
There was a problem hiding this comment.
Having a second look at this, 0xMiden/protocol#2691 changed the encoding format of NoteType, thus why we can no longer have it as 1-indexed:
- NoteType::Private changed from 2 to 0 (new default)
- NoteType::Public remains 1
There was a problem hiding this comment.
should this .mac files be (git) ignored?
There was a problem hiding this comment.
No I think they're added intentionally as examples
|
|
||
| let component = BasicFungibleFaucet::new(symbol.as_ref().clone(), decimals, max_supply)?; | ||
| let token_metadata = FungibleTokenMetadata::builder( | ||
| TokenName::new("").expect("empty token name is always valid"), |
There was a problem hiding this comment.
What is TokenName and shouldn't we be providing one?
There was a problem hiding this comment.
TokenName was added to the protocol recently and represents the display name of a token. I agree that we should provide one here, at least we should match the token symbol
There was a problem hiding this comment.
The token name is now derived from the symbol.
| .with_component(BasicFungibleFaucet) | ||
| .with_component(MintAuthControlled::allow_all()) | ||
| .with_component(BurnAuthControlled::allow_all()) |
There was a problem hiding this comment.
Now that there are so many more options, should we be allowing non-native faucets by config at all? Or is this still a sensible default to use.
| note_id BLOB NOT NULL, | ||
| note_commitment BLOB NOT NULL, | ||
| note_type INTEGER NOT NULL, -- 1-Public (0b01), 2-Private (0b10), 3-Encrypted (0b11) | ||
| note_type INTEGER NOT NULL, -- 0-Private, 1-Public |
There was a problem hiding this comment.
Is this comment correct though? The PR you linked still has them as 1 and 2, https://github.com/0xMiden/protocol/pull/2315/changes#diff-c3b6ee362a233a6ad5b487e48cd19fb6ca264834b8f015e2daa72a1180d6c32fR16-R17
|
|
||
| let component = BasicFungibleFaucet::new(symbol.as_ref().clone(), decimals, max_supply)?; | ||
| let token_metadata = FungibleTokenMetadata::builder( | ||
| TokenName::new("").expect("empty token name is always valid"), |
There was a problem hiding this comment.
TokenName was added to the protocol recently and represents the display name of a token. I agree that we should provide one here, at least we should match the token symbol
| - [BREAKING] Network monitor `/status` endpoint now emits a single `RemoteProverStatus` entry per remote prover that bundles status, workers, and test results, instead of separate entries ([#1980](https://github.com/0xMiden/node/pull/1980)). | ||
| - Refactored the validator gRPC API implementation to use the new per-method trait implementations ([#1959](https://github.com/0xMiden/node/pull/1959)). | ||
| - Aligned `SyncNullifiers` list-limit validation in RPC and store with `nullifier_prefix` parameter semantics, extended `GetLimits` test coverage, and documented query parameter limits ([#1986](https://github.com/0xMiden/node/pull/1986)). | ||
| - Fixed remote-prover grpc server not using configured timeout ([#2023](https://github.com/0xMiden/node/pull/2023)). |
There was a problem hiding this comment.
Is this changelog entry right? 🤔
There was a problem hiding this comment.
It is was! You can see the change in the first commit, but it appears as it has been fixed on next as well. I'll remove the entry.
There was a problem hiding this comment.
Removed in d1c0648
Should we mark this as no changelog?
3 participants
Update
miden-protocoldependencies to point back tonextin order to prepare for0.15.0release.