2022-07-16 21:49:35 +00:00
|
|
|
# This file is automatically @generated by Cargo.
|
|
|
|
# It is not intended for manual editing.
|
|
|
|
version = 3
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "Inflector"
|
|
|
|
version = "0.11.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fe438c63458706e03479442743baae6c88256498e6431708f6dfc520a26515d3"
|
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"regex",
|
|
|
|
]
|
|
|
|
|
2022-12-21 04:12:26 +00:00
|
|
|
[[package]]
|
|
|
|
name = "addr2line"
|
2023-08-23 02:06:06 +00:00
|
|
|
version = "0.20.0"
|
2022-12-21 04:12:26 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 02:06:06 +00:00
|
|
|
checksum = "f4fa78e18c64fce05e902adecd7a5eed15a5e0a3439f7b0e169f0252214865e3"
|
2022-12-21 04:12:26 +00:00
|
|
|
dependencies = [
|
2023-08-23 02:06:06 +00:00
|
|
|
"gimli 0.27.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-07-02 00:27:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "addr2line"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.22.0"
|
2023-07-02 00:27:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "6e4503c46a5c0c7844e948c9a4d6acd9f50cccb4de1c48eb9e291ea17470c678"
|
2023-07-02 00:27:03 +00:00
|
|
|
dependencies = [
|
2024-06-13 19:57:08 +00:00
|
|
|
"gimli 0.29.0",
|
2023-07-02 00:27:03 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "adler"
|
|
|
|
version = "1.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f26201604c87b1e01bd3d98f8d5d9a8fcbb815e8cedb41ffccbeb4bf593a35fe"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aead"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.5.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "d122413f284cf2d62fb1b7db97e02edb8cda96d769b16e443a4f6195e35662b0"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-11-12 05:40:32 +00:00
|
|
|
"crypto-common",
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aes"
|
2024-02-25 23:37:15 +00:00
|
|
|
version = "0.8.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-25 23:37:15 +00:00
|
|
|
checksum = "b169f7a6d4742236a0a00c541b845991d0ac43e546831af1249753ab4c3aa3a0"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-11-12 05:40:32 +00:00
|
|
|
"cipher",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cpufeatures",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "aes-gcm"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.10.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "831010a0f742e1209b3bcea8fab6a8e149051ba6099432c8cb2cc117dec3ead1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"aead",
|
2023-11-09 18:22:43 +00:00
|
|
|
"aes",
|
2023-11-12 05:40:32 +00:00
|
|
|
"cipher",
|
2023-11-09 18:22:43 +00:00
|
|
|
"ctr",
|
2023-07-28 03:38:04 +00:00
|
|
|
"ghash",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ahash"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "0.8.11"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "e89da841a80418a9b391ebaea17f5c112ffaaa96f621d2c285b5174da76b9011"
|
2023-03-06 12:39:43 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-10-16 19:07:39 +00:00
|
|
|
"getrandom",
|
2023-03-06 12:39:43 +00:00
|
|
|
"once_cell",
|
|
|
|
"version_check",
|
2023-10-24 08:03:51 +00:00
|
|
|
"zerocopy",
|
2023-03-06 12:39:43 +00:00
|
|
|
]
|
|
|
|
|
2023-04-23 23:21:24 +00:00
|
|
|
[[package]]
|
|
|
|
name = "aho-corasick"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "1.1.3"
|
2023-04-23 23:21:24 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "8e60d3430d3a69478ad0993f19238d2df97c507009a52b3c10addcd7f6bcb916"
|
2023-04-23 23:21:24 +00:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
2023-06-29 01:16:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "allocator-api2"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
version = "0.2.18"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5c6cb57a04249c6480766f7f7cef5467412af1490f8d1e243141daddada3264f"
|
|
|
|
|
2024-06-13 19:57:08 +00:00
|
|
|
[[package]]
|
|
|
|
name = "alloy-chains"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.29"
|
2024-06-13 19:57:08 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "bb07629a5d0645d29f68d2fb6f4d0cf15c89ec0965be915f303967180929743f"
|
2024-06-13 19:57:08 +00:00
|
|
|
dependencies = [
|
|
|
|
"num_enum",
|
2024-07-15 00:27:36 +00:00
|
|
|
"strum 0.26.3",
|
2024-06-13 19:57:08 +00:00
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "alloy-consensus"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "4177d135789e282e925092be8939d421b701c6d92c0a16679faa659d9166289d"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-eips",
|
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-rlp",
|
|
|
|
"alloy-serde",
|
|
|
|
"c-kzg",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-core"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8e6dbb79f4e3285cc87f50c0d4be9a3a812643623b2e3558d425b41cbd795ceb"
|
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-eip2930"
|
|
|
|
version = "0.1.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "0069cf0642457f87a01a014f6dc29d5d893cd4fd8fddf0c3cdfad1bb3ebafc41"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
2024-09-05 21:03:23 +00:00
|
|
|
"alloy-rlp",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-eip7702"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "37d319bb544ca6caeab58c39cea8921c55d924d4f68f2c60f24f914673f9a74a"
|
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-rlp",
|
|
|
|
"k256",
|
|
|
|
"serde",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-eips"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "499ee14d296a133d142efd215eb36bf96124829fe91cf8f5d4e5ccdd381eae00"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"alloy-eip2930",
|
|
|
|
"alloy-eip7702",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-rlp",
|
|
|
|
"alloy-serde",
|
|
|
|
"c-kzg",
|
2024-09-05 21:03:23 +00:00
|
|
|
"derive_more 1.0.0",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"once_cell",
|
|
|
|
"serde",
|
2024-05-10 17:33:56 +00:00
|
|
|
"sha2",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-genesis"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "4b85dfc693e4a1193f0372a8f789df12ab51fcbe7be0733baa04939a86dd813b"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-serde",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-json-abi"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "299d2a937b6c60968df3dad2a988b0f0e03277b344639a4f7a31bd68e6285e59"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-sol-type-parser",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-json-rpc"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "4207166c79cfdf7f3bed24bbc84f5c7c5d4db1970f8c82e3fcc76257f16d2166"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
2024-09-05 21:03:23 +00:00
|
|
|
"alloy-sol-types",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"thiserror",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-network"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "dfbe2802d5b8c632f18d68c352073378f02a3407c1b6a4487194e7d21ab0f002"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-consensus",
|
|
|
|
"alloy-eips",
|
|
|
|
"alloy-json-rpc",
|
2024-09-05 21:03:23 +00:00
|
|
|
"alloy-network-primitives",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-primitives",
|
2024-06-13 19:57:08 +00:00
|
|
|
"alloy-rpc-types-eth",
|
2024-06-19 16:39:47 +00:00
|
|
|
"alloy-serde",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-signer",
|
2024-05-10 17:33:56 +00:00
|
|
|
"alloy-sol-types",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"async-trait",
|
2024-06-13 19:57:08 +00:00
|
|
|
"auto_impl",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"futures-utils-wasm",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2024-09-05 21:03:23 +00:00
|
|
|
[[package]]
|
|
|
|
name = "alloy-network-primitives"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "396c07726030fa0f9dab5da8c71ccd69d5eb74a7fe1072b7ae453a67e4fe553e"
|
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-serde",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "alloy-node-bindings"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "c847311cc7386684ef38ab404069d795bee07da945f63d884265436870a17276"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-genesis",
|
|
|
|
"alloy-primitives",
|
|
|
|
"k256",
|
|
|
|
"serde_json",
|
|
|
|
"tempfile",
|
|
|
|
"thiserror",
|
|
|
|
"tracing",
|
|
|
|
"url",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-primitives"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "a767e59c86900dd7c3ce3ecef04f3ace5ac9631ee150beb8b7d22f7fa3bbb2d7"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-rlp",
|
|
|
|
"bytes",
|
|
|
|
"cfg-if",
|
|
|
|
"const-hex",
|
2024-09-05 21:03:23 +00:00
|
|
|
"derive_more 0.99.18",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"hex-literal",
|
|
|
|
"itoa",
|
|
|
|
"k256",
|
|
|
|
"keccak-asm",
|
|
|
|
"proptest",
|
|
|
|
"rand",
|
|
|
|
"ruint",
|
|
|
|
"serde",
|
|
|
|
"tiny-keccak",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-provider"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "1376948df782ffee83a54cac4b2aba14134edd997229a3db97da0a606586eb5c"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
2024-06-13 19:57:08 +00:00
|
|
|
"alloy-chains",
|
|
|
|
"alloy-consensus",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-eips",
|
|
|
|
"alloy-json-rpc",
|
|
|
|
"alloy-network",
|
2024-09-05 21:03:23 +00:00
|
|
|
"alloy-network-primitives",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-rpc-client",
|
2024-06-13 19:57:08 +00:00
|
|
|
"alloy-rpc-types-eth",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-transport",
|
|
|
|
"async-stream",
|
|
|
|
"async-trait",
|
|
|
|
"auto_impl",
|
|
|
|
"dashmap",
|
|
|
|
"futures",
|
|
|
|
"futures-utils-wasm",
|
|
|
|
"lru",
|
2024-05-21 10:09:04 +00:00
|
|
|
"pin-project",
|
2024-06-13 19:57:08 +00:00
|
|
|
"serde",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"serde_json",
|
2024-09-05 21:03:23 +00:00
|
|
|
"thiserror",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"tokio",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-rlp"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.8"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "26154390b1d205a4a7ac7352aa2eb4f81f391399d4e2f546fb81a2f8bb383f62"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-rlp-derive",
|
|
|
|
"arrayvec",
|
|
|
|
"bytes",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-rlp-derive"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.8"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "4d0f2d905ebd295e7effec65e5f6868d153936130ae718352771de3e7d03c75c"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-rpc-client"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "02378418a429f8a14a0ad8ffaa15b2d25ff34914fc4a1e366513c6a3800e03b3"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-json-rpc",
|
|
|
|
"alloy-transport",
|
|
|
|
"alloy-transport-http",
|
|
|
|
"futures",
|
|
|
|
"pin-project",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"tokio",
|
|
|
|
"tokio-stream",
|
|
|
|
"tower",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2024-06-13 19:57:08 +00:00
|
|
|
name = "alloy-rpc-types-eth"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "15bb3506ab1cf415d4752778c93e102050399fb8de97b7da405a5bf3e31f5f3b"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-consensus",
|
|
|
|
"alloy-eips",
|
2024-09-05 21:03:23 +00:00
|
|
|
"alloy-network-primitives",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-rlp",
|
|
|
|
"alloy-serde",
|
|
|
|
"alloy-sol-types",
|
2024-06-19 16:39:47 +00:00
|
|
|
"itertools 0.13.0",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-serde"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "ae417978015f573b4a8c02af17f88558fb22e3fccd12e8a910cf6a2ff331cfcb"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-signer"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "b750c9b61ac0646f8f4a61231c2732a337b2c829866fc9a191b96b7eedf80ffe"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-primitives",
|
|
|
|
"async-trait",
|
|
|
|
"auto_impl",
|
|
|
|
"elliptic-curve",
|
|
|
|
"k256",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-simple-request-transport"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"alloy-json-rpc",
|
|
|
|
"alloy-transport",
|
|
|
|
"serde_json",
|
|
|
|
"simple-request",
|
|
|
|
"tower",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-sol-macro"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "183bcfc0f3291d9c41a3774172ee582fb2ce6eb6569085471d8f225de7bb86fc"
|
2024-05-21 10:09:04 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-sol-macro-expander",
|
|
|
|
"alloy-sol-macro-input",
|
|
|
|
"proc-macro-error",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2024-05-21 10:09:04 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-sol-macro-expander"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
2024-05-21 10:09:04 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "71c4d842beb7a6686d04125603bc57614d5ed78bf95e4753274db3db4ba95214"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-json-abi",
|
|
|
|
"alloy-sol-macro-input",
|
|
|
|
"const-hex",
|
2024-06-13 19:57:08 +00:00
|
|
|
"heck 0.5.0",
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"proc-macro-error",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"syn-solidity",
|
|
|
|
"tiny-keccak",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-sol-macro-input"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "1306e8d3c9e6e6ecf7a39ffaf7291e73a5f655a2defd366ee92c2efebcdf7fee"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-json-abi",
|
|
|
|
"const-hex",
|
|
|
|
"dunce",
|
|
|
|
"heck 0.5.0",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"serde_json",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"syn-solidity",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-sol-type-parser"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
2024-09-06 03:31:45 +00:00
|
|
|
source = "git+https://github.com/alloy-rs/core?rev=446b9d2fbce12b88456152170709a3eaac929af0#446b9d2fbce12b88456152170709a3eaac929af0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"serde",
|
2024-08-01 08:06:09 +00:00
|
|
|
"winnow 0.6.18",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-sol-types"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
2023-06-29 01:16:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "577e262966e92112edbd15b1b2c0947cc434d6e8311df96d3329793fe8047da9"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-json-abi",
|
|
|
|
"alloy-primitives",
|
|
|
|
"alloy-sol-macro",
|
|
|
|
"const-hex",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-transport"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "2799749ca692ae145f54968778877afd7c95e788488f176cfdfcf2a8abeb2062"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-json-rpc",
|
2024-05-21 10:09:04 +00:00
|
|
|
"base64 0.22.1",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"futures-util",
|
|
|
|
"futures-utils-wasm",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
"tower",
|
2024-07-15 00:27:36 +00:00
|
|
|
"tracing",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"url",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "alloy-transport-http"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2024-06-19 16:39:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "bc10c4dd932f66e0db6cc5735241e0c17a6a18564b430bbc1839f7db18587a93"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-transport",
|
|
|
|
"url",
|
|
|
|
]
|
2023-06-29 01:16:33 +00:00
|
|
|
|
2023-06-22 10:25:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "android-tzdata"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e999941b234f3131b00bc13c22d06e8c5ff726d1b6318ac7eb276997bbb4fef0"
|
|
|
|
|
2022-08-16 07:44:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "android_system_properties"
|
2022-09-18 19:30:38 +00:00
|
|
|
version = "0.1.5"
|
2022-08-16 07:44:32 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-09-18 19:30:38 +00:00
|
|
|
checksum = "819e7219dbd41043ac279b19830f2efc897156490d7fd6ea916720117ee66311"
|
2022-08-16 07:44:32 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ansi_term"
|
|
|
|
version = "0.12.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d52a9bb7ec0cf484c551830a7ce27bd20d67eac647e1befb56b0be4ee39a55d2"
|
|
|
|
dependencies = [
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
2023-03-31 06:34:52 +00:00
|
|
|
[[package]]
|
|
|
|
name = "anstream"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.6.15"
|
2023-03-31 06:34:52 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "64e15c1ab1f89faffbf04a634d5e1962e9074f2741eef6d97f3c4e322426d526"
|
2023-03-31 06:34:52 +00:00
|
|
|
dependencies = [
|
|
|
|
"anstyle",
|
|
|
|
"anstyle-parse",
|
2023-04-14 01:05:18 +00:00
|
|
|
"anstyle-query",
|
2023-03-31 06:34:52 +00:00
|
|
|
"anstyle-wincon",
|
2023-04-14 01:05:18 +00:00
|
|
|
"colorchoice",
|
2024-05-21 12:07:32 +00:00
|
|
|
"is_terminal_polyfill",
|
2023-03-31 06:34:52 +00:00
|
|
|
"utf8parse",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "anstyle"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.0.8"
|
2023-03-31 06:34:52 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "1bec1de6f59aedf83baf9ff929c98f2ad654b97c9510f4e70cf6f661d49fd5b1"
|
2023-03-31 06:34:52 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "anstyle-parse"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.2.5"
|
2023-03-31 06:34:52 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "eb47de1e80c2b463c735db5b217a0ddc39d612e7ac9e2e96a5aed1f57616c1cb"
|
2023-03-31 06:34:52 +00:00
|
|
|
dependencies = [
|
|
|
|
"utf8parse",
|
|
|
|
]
|
|
|
|
|
2023-04-14 01:05:18 +00:00
|
|
|
[[package]]
|
|
|
|
name = "anstyle-query"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.1.1"
|
2023-04-14 01:05:18 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "6d36fc52c7f6c869915e99412912f22093507da8d9e942ceaf66fe4b7c14422a"
|
2023-04-14 01:05:18 +00:00
|
|
|
dependencies = [
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.52.0",
|
2023-04-14 01:05:18 +00:00
|
|
|
]
|
|
|
|
|
2023-03-31 06:34:52 +00:00
|
|
|
[[package]]
|
|
|
|
name = "anstyle-wincon"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "3.0.4"
|
2023-03-31 06:34:52 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "5bf74e1b6e971609db8ca7a9ce79fd5768ab6ae46441c572e46cf596f59e57f8"
|
2023-03-31 06:34:52 +00:00
|
|
|
dependencies = [
|
|
|
|
"anstyle",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.52.0",
|
2023-03-31 06:34:52 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "anyhow"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.0.86"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "b3d1d046238990b9cf5bcde22a3fb3584ee5cf65fb2765f454ed428c7a0063da"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "approx"
|
|
|
|
version = "0.5.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cab112f0a86d568ea0e627cc1d6be74a1e9cd55214684db5561995f6dad897c6"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "arbitrary"
|
2023-11-06 12:19:55 +00:00
|
|
|
version = "1.3.2"
|
2023-08-23 02:06:06 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-06 12:19:55 +00:00
|
|
|
checksum = "7d5a26814d8dcb93b0e5a0ff3c6d80a8843bafb21b39e8e18a6f05471870e110"
|
2023-08-23 02:06:06 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ark-ff"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6b3235cc41ee7a12aaaf2c575a2ad7b46713a8a50bda2fc3b003a04845c05dd6"
|
|
|
|
dependencies = [
|
|
|
|
"ark-ff-asm 0.3.0",
|
|
|
|
"ark-ff-macros 0.3.0",
|
|
|
|
"ark-serialize 0.3.0",
|
|
|
|
"ark-std 0.3.0",
|
|
|
|
"derivative",
|
|
|
|
"num-bigint",
|
|
|
|
"num-traits",
|
|
|
|
"paste",
|
|
|
|
"rustc_version 0.3.3",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-ff"
|
|
|
|
version = "0.4.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ec847af850f44ad29048935519032c33da8aa03340876d351dfab5660d2966ba"
|
|
|
|
dependencies = [
|
|
|
|
"ark-ff-asm 0.4.2",
|
|
|
|
"ark-ff-macros 0.4.2",
|
|
|
|
"ark-serialize 0.4.2",
|
|
|
|
"ark-std 0.4.0",
|
|
|
|
"derivative",
|
|
|
|
"digest 0.10.7",
|
|
|
|
"itertools 0.10.5",
|
|
|
|
"num-bigint",
|
|
|
|
"num-traits",
|
|
|
|
"paste",
|
2024-09-05 21:03:23 +00:00
|
|
|
"rustc_version 0.4.1",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-ff-asm"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "db02d390bf6643fb404d3d22d31aee1c4bc4459600aef9113833d17e786c6e44"
|
|
|
|
dependencies = [
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-ff-asm"
|
|
|
|
version = "0.4.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3ed4aa4fe255d0bc6d79373f7e31d2ea147bcf486cba1be5ba7ea85abdb92348"
|
|
|
|
dependencies = [
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-ff-macros"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "db2fd794a08ccb318058009eefdf15bcaaaaf6f8161eb3345f907222bac38b20"
|
|
|
|
dependencies = [
|
|
|
|
"num-bigint",
|
|
|
|
"num-traits",
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-ff-macros"
|
|
|
|
version = "0.4.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7abe79b0e4288889c4574159ab790824d0033b9fdcb2a112a3182fac2e514565"
|
|
|
|
dependencies = [
|
|
|
|
"num-bigint",
|
|
|
|
"num-traits",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-serialize"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1d6c2b318ee6e10f8c2853e73a83adc0ccb88995aa978d8a3408d492ab2ee671"
|
|
|
|
dependencies = [
|
|
|
|
"ark-std 0.3.0",
|
|
|
|
"digest 0.9.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-serialize"
|
|
|
|
version = "0.4.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "adb7b85a02b83d2f22f89bd5cac66c9c89474240cb6207cb1efc16d098e822a5"
|
|
|
|
dependencies = [
|
|
|
|
"ark-std 0.4.0",
|
|
|
|
"digest 0.10.7",
|
|
|
|
"num-bigint",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-std"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1df2c09229cbc5a028b1d70e00fdb2acee28b1055dfb5ca73eea49c5a25c4e7c"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
"rand",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ark-std"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "94893f1e0c6eeab764ade8dc4c0db24caf4fe7cbbaafc0eba0a9030f447b5185"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
"rand",
|
|
|
|
]
|
|
|
|
|
2022-07-17 21:17:23 +00:00
|
|
|
[[package]]
|
2022-09-29 18:33:09 +00:00
|
|
|
name = "array-bytes"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "6.2.3"
|
2022-07-17 21:17:23 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "5d5dde061bd34119e902bbb2d9b90c5692635cf59fb91d582c2b68043f1b8293"
|
2022-07-17 21:17:23 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "arrayref"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.3.8"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "9d151e35f61089500b617991b791fc8bfd237ae50cd5950803758a179b41e67a"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "arrayvec"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.7.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "7c02d123df017efcdfbd739ef81735b36c5ba83ec3c59c80a9d7ecc718f92e50"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "asn1-rs"
|
|
|
|
version = "0.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7f6fd5ddaf0351dff5b8da21b2fb4ff8e08ddd02857f0bf69c47639106c0fff0"
|
|
|
|
dependencies = [
|
|
|
|
"asn1-rs-derive",
|
|
|
|
"asn1-rs-impl",
|
|
|
|
"displaydoc",
|
|
|
|
"nom",
|
|
|
|
"num-traits",
|
|
|
|
"rusticata-macros",
|
|
|
|
"thiserror",
|
2023-09-12 11:47:03 +00:00
|
|
|
"time",
|
2023-08-25 03:55:47 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "asn1-rs-derive"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "726535892e8eae7e70657b4c8ea93d26b8553afb1ce617caee529ef96d7dee6c"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
"synstructure",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "asn1-rs-impl"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2777730b2039ac0f95f093556e61b6d26cebed5393ca6f152717777cec3a42ed"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "async-channel"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "1.9.0"
|
2023-03-26 12:43:01 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "81953c529336010edd6d8e358f886d9581267795c61b19475b71314bffa46d35"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"concurrent-queue",
|
2023-11-22 06:24:17 +00:00
|
|
|
"event-listener 2.5.3",
|
2023-03-26 12:43:01 +00:00
|
|
|
"futures-core",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "async-io"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "2.3.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "444b0228950ee6501b3568d3c93bf1176a1fdbc3b758dcd9475046d30f4dc7e8"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-11-28 07:29:50 +00:00
|
|
|
"async-lock",
|
2023-03-25 04:45:33 +00:00
|
|
|
"cfg-if",
|
2022-12-07 22:56:53 +00:00
|
|
|
"concurrent-queue",
|
2023-11-22 06:24:17 +00:00
|
|
|
"futures-io",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures-lite",
|
|
|
|
"parking",
|
|
|
|
"polling",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2022-07-16 21:49:35 +00:00
|
|
|
"slab",
|
2023-11-22 06:24:17 +00:00
|
|
|
"tracing",
|
2024-09-05 21:03:23 +00:00
|
|
|
"windows-sys 0.59.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-lock"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "3.4.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "ff6e472cdea888a4bd64f342f09b3f50e1886d32afe8df3d663c01140b811b18"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-06-13 19:57:08 +00:00
|
|
|
"event-listener 5.3.1",
|
2023-11-22 06:24:17 +00:00
|
|
|
"event-listener-strategy",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
name = "async-stream"
|
|
|
|
version = "0.3.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
checksum = "cd56dd203fef61ac097dd65721a419ddccb106b2d2b70ba60a6b529f03961a51"
|
|
|
|
dependencies = [
|
|
|
|
"async-stream-impl",
|
|
|
|
"futures-core",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "async-stream-impl"
|
|
|
|
version = "0.3.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "16e62a023e7c117e27523144c5d2459f4397fcc3cab0085af8e2224f643a0193"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
name = "async-trait"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.82"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "a27b8a3a6e1a44fa4c8baf1f653e4172e81486d4941f2237e20dc2d0cf4ddff1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "asynchronous-codec"
|
2023-07-24 08:54:13 +00:00
|
|
|
version = "0.6.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-24 08:54:13 +00:00
|
|
|
checksum = "4057f2c32adbb2fc158e22fb38433c8e9bbf76b75a4732c7c0cbaf695fb65568"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-util",
|
|
|
|
"memchr",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-10-19 04:27:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "attohttpc"
|
|
|
|
version = "0.24.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8d9a9bf8b79a749ee0b911b91b671cc2b6c670bdbc7e3dfd537576ddc94bb2a2"
|
|
|
|
dependencies = [
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2023-10-19 04:27:21 +00:00
|
|
|
"log",
|
|
|
|
"url",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "auto_impl"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "1.2.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "3c87f3f15e7794432337fc718554eaa4dc8f04c9677a950ffe366f20a162ae42"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "autocfg"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.3.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "0c4b4d0bd25bd0b74681c0ad21497610ce1b7c91b1022cd21c80c6fbdd9476b0"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "backtrace"
|
2024-06-19 16:39:47 +00:00
|
|
|
version = "0.3.73"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-19 16:39:47 +00:00
|
|
|
checksum = "5cc23269a4f8976d0a4d2e7109211a419fe30e8d88d677cd60b6bc79c5732e0a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-06-13 19:57:08 +00:00
|
|
|
"addr2line 0.22.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cc",
|
|
|
|
"cfg-if",
|
|
|
|
"libc",
|
2023-07-02 00:27:03 +00:00
|
|
|
"miniz_oxide",
|
2024-09-05 21:03:23 +00:00
|
|
|
"object 0.36.4",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rustc-demangle",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "base-x"
|
|
|
|
version = "0.2.11"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4cbbc9d0964165b47557570cce6c952866c2678457aca742aafc9fb771d30270"
|
|
|
|
|
|
|
|
[[package]]
|
2023-03-25 04:45:33 +00:00
|
|
|
name = "base16ct"
|
|
|
|
version = "0.2.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-25 04:45:33 +00:00
|
|
|
checksum = "4c7f02d4ea65f2c1853089ffd8d2787bdbc63de2f0d29dedbcf8ccdfa0ccd4cf"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2024-05-21 09:27:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "base58ck"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2c8d66485a3a2ea485c1913c4572ce0256067a5377ac8c75c4960e1cda98605f"
|
|
|
|
dependencies = [
|
|
|
|
"bitcoin-internals",
|
|
|
|
"bitcoin_hashes",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "base64"
|
2022-10-22 01:40:50 +00:00
|
|
|
version = "0.13.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-10-22 01:40:50 +00:00
|
|
|
checksum = "9e1b586273c5702936fe7b7d6896644d8be71e6314cfe09d3167c95f712589e8"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-01-16 15:42:31 +00:00
|
|
|
[[package]]
|
|
|
|
name = "base64"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "0.21.7"
|
2023-01-16 15:42:31 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "9d297deb1925b89f2ccc13d7635fa0714f12c87adce1c75356b39ca9b7178567"
|
2023-01-16 15:42:31 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "base64"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.22.1"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "72b3254f16251a8381aa12e40e3c4d2f0199f8c6508fbecb9d91f575e0fbb8c6"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "base64ct"
|
2023-03-06 12:39:43 +00:00
|
|
|
version = "1.6.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-06 12:39:43 +00:00
|
|
|
checksum = "8c3c1a368f70d6cf7302d78f8f7093da241fb8e8807c05cc9e51a125895a6d5b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-10-30 08:45:20 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bech32"
|
2024-05-21 09:27:01 +00:00
|
|
|
version = "0.11.0"
|
2023-10-30 08:45:20 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 09:27:01 +00:00
|
|
|
checksum = "d965446196e3b7decd44aa7ee49e31d630118f90ef12f97900f262eb915c951d"
|
2023-10-30 08:45:20 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "beef"
|
|
|
|
version = "0.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3a8241f3ebb85c056b509d4327ad0358fbbba6ffb340bf388f26350aeda225b1"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bincode"
|
|
|
|
version = "1.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b1f45e9417d87227c7a56d22e471c6206462cba514c7590c09aff4cf6d1ddcad"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bindgen"
|
2024-03-09 06:58:58 +00:00
|
|
|
version = "0.69.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-09 06:58:58 +00:00
|
|
|
checksum = "a00dc851838a2120612785d195287475a3ac45514741da670b735818822129a0"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cexpr",
|
|
|
|
"clang-sys",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"itertools 0.12.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"lazy_static",
|
|
|
|
"lazycell",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"regex",
|
|
|
|
"rustc-hash",
|
|
|
|
"shlex",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bit-set"
|
|
|
|
version = "0.5.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0700ddab506f33b20a03b13996eccd309a48e5ff77d0d95926aa0210fb4e95f1"
|
|
|
|
dependencies = [
|
|
|
|
"bit-vec",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bit-vec"
|
|
|
|
version = "0.6.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "349f9b6a179ed607305526ca489b34ad0a41aed5f7980fa90eb03160b69598fb"
|
|
|
|
|
2023-01-31 12:48:14 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bitcoin"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.32.2"
|
2023-01-31 12:48:14 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "ea507acc1cd80fc084ace38544bbcf7ced7c2aa65b653b102de0ce718df668f6"
|
2023-01-31 12:48:14 +00:00
|
|
|
dependencies = [
|
2024-05-21 09:27:01 +00:00
|
|
|
"base58ck",
|
2023-11-09 18:22:43 +00:00
|
|
|
"bech32",
|
2023-10-30 08:45:20 +00:00
|
|
|
"bitcoin-internals",
|
2024-05-21 09:27:01 +00:00
|
|
|
"bitcoin-io",
|
|
|
|
"bitcoin-units",
|
2023-01-31 12:48:14 +00:00
|
|
|
"bitcoin_hashes",
|
2023-10-30 08:45:20 +00:00
|
|
|
"hex-conservative",
|
2023-04-09 06:31:10 +00:00
|
|
|
"hex_lit",
|
2023-01-31 12:48:14 +00:00
|
|
|
"secp256k1",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2023-04-09 06:31:10 +00:00
|
|
|
[[package]]
|
2023-10-30 08:45:20 +00:00
|
|
|
name = "bitcoin-internals"
|
2024-05-21 09:27:01 +00:00
|
|
|
version = "0.3.0"
|
2023-04-09 06:31:10 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 09:27:01 +00:00
|
|
|
checksum = "30bdbe14aa07b06e6cfeffc529a1f099e5fbe249524f8125358604df99a4bed2"
|
2023-10-30 08:45:20 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
2023-04-09 06:31:10 +00:00
|
|
|
|
2024-05-21 09:27:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bitcoin-io"
|
|
|
|
version = "0.1.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "340e09e8399c7bd8912f495af6aa58bea0c9214773417ffaa8f6460f93aaee56"
|
|
|
|
|
2023-01-31 12:48:14 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bitcoin-serai"
|
2023-08-21 06:38:27 +00:00
|
|
|
version = "0.3.0"
|
2023-01-31 12:48:14 +00:00
|
|
|
dependencies = [
|
|
|
|
"bitcoin",
|
|
|
|
"hex",
|
2023-03-28 08:38:01 +00:00
|
|
|
"k256",
|
2023-01-31 12:48:14 +00:00
|
|
|
"modular-frost",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-01-31 12:48:14 +00:00
|
|
|
"secp256k1",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2023-11-06 14:14:46 +00:00
|
|
|
"simple-request",
|
2023-08-21 12:56:37 +00:00
|
|
|
"std-shims",
|
2023-01-31 12:48:14 +00:00
|
|
|
"thiserror",
|
2023-03-18 01:25:38 +00:00
|
|
|
"tokio",
|
2023-03-18 00:47:42 +00:00
|
|
|
"zeroize",
|
2023-01-31 12:48:14 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2024-05-21 09:27:01 +00:00
|
|
|
name = "bitcoin-units"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.1.2"
|
2023-01-31 12:48:14 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "5285c8bcaa25876d07f37e3d30c303f2609179716e11d688f51e8f1fe70063e2"
|
2023-01-31 12:48:14 +00:00
|
|
|
dependencies = [
|
2023-10-30 08:45:20 +00:00
|
|
|
"bitcoin-internals",
|
2024-05-21 09:27:01 +00:00
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bitcoin_hashes"
|
|
|
|
version = "0.14.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bb18c03d0db0247e147a21a6faafd5a7eb851c743db062de72018b6b7e8e4d16"
|
|
|
|
dependencies = [
|
|
|
|
"bitcoin-io",
|
2023-10-30 08:45:20 +00:00
|
|
|
"hex-conservative",
|
2023-01-31 12:48:14 +00:00
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bitflags"
|
|
|
|
version = "1.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bef38d45163c2f1dde094a7dfd33ccf595c92905c8f8f4fdc18d06fb1037718a"
|
|
|
|
|
2023-06-28 18:57:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bitflags"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "2.6.0"
|
2023-06-28 18:57:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "b048fb63fd8b5923fc5aa7b340d8e156aec7ec02f0c78fa8a6ddc2613f6f71de"
|
2023-06-28 18:57:58 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bitvec"
|
|
|
|
version = "1.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1bc2832c24239b0141d5674bb9174f9d68a8b5b3f2753311927c172ca46f7e9c"
|
|
|
|
dependencies = [
|
|
|
|
"funty",
|
2023-08-23 17:24:21 +00:00
|
|
|
"radium",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tap",
|
|
|
|
"wyz",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "blake2"
|
2022-12-21 04:12:26 +00:00
|
|
|
version = "0.10.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-12-21 04:12:26 +00:00
|
|
|
checksum = "46502ad458c9a52b69d4d4d32775c788b7a1b85e8bc9d482d92250fc0e3f8efe"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "blake2b_simd"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "1.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "23285ad32269793932e830392f2fe2f83e26488fd3ec778883a93c8323735780"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"arrayref",
|
2023-04-08 08:44:28 +00:00
|
|
|
"arrayvec",
|
2023-09-12 11:47:03 +00:00
|
|
|
"constant_time_eq",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "blake2s_simd"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "1.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "94230421e395b9920d23df13ea5d77a20e1725331f90fbbf6df6040b33f756ae"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"arrayref",
|
2023-04-08 08:44:28 +00:00
|
|
|
"arrayvec",
|
2023-09-12 11:47:03 +00:00
|
|
|
"constant_time_eq",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "blake3"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.5.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "d82033247fd8e890df8f740e407ad4d038debb9eb1f40533fffb32e7d17dc6f7"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"arrayref",
|
2023-04-08 08:44:28 +00:00
|
|
|
"arrayvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cc",
|
|
|
|
"cfg-if",
|
2023-09-12 11:47:03 +00:00
|
|
|
"constant_time_eq",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "block-buffer"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4152116fd6e9dadb291ae18fc1ec3575ed6d84c29642d97890f4b4a3417297e4"
|
|
|
|
dependencies = [
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "block-buffer"
|
2023-03-11 09:49:05 +00:00
|
|
|
version = "0.10.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-11 09:49:05 +00:00
|
|
|
checksum = "3078c7629b62d3f0439517fa394996acacc5cbc91c5a20d8c658e77abd503a71"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-10-31 11:41:23 +00:00
|
|
|
[[package]]
|
|
|
|
name = "block-padding"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a8894febbff9f758034a5b8e12d87918f56dfc64a8e1fe757d65e29041538d93"
|
|
|
|
dependencies = [
|
|
|
|
"generic-array 0.14.7",
|
|
|
|
]
|
|
|
|
|
2023-03-28 08:38:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bls12_381"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d7bc6d6292be3a19e6379786dac800f551e5865a5bb51ebbe3064ab80433f403"
|
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"ff",
|
|
|
|
"group",
|
2023-03-28 08:38:01 +00:00
|
|
|
"pairing",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-28 08:38:01 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "blst"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.3.13"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "4378725facc195f1a538864863f6de233b500a8862747e7f165078a419d5e874"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"glob",
|
|
|
|
"threadpool",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-07-20 22:53:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bollard"
|
2024-09-06 03:31:45 +00:00
|
|
|
version = "0.17.1"
|
2023-07-20 22:53:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-06 03:31:45 +00:00
|
|
|
checksum = "d41711ad46fda47cd701f6908e59d1bd6b9a2b7464c0d0aeab95c6d37096ff8a"
|
2023-07-20 22:53:03 +00:00
|
|
|
dependencies = [
|
2024-09-06 03:31:45 +00:00
|
|
|
"base64 0.22.1",
|
2023-07-20 22:53:03 +00:00
|
|
|
"bollard-stubs",
|
|
|
|
"bytes",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"hex",
|
2024-09-06 03:31:45 +00:00
|
|
|
"http 1.1.0",
|
|
|
|
"http-body-util",
|
|
|
|
"hyper 1.4.1",
|
|
|
|
"hyper-named-pipe",
|
|
|
|
"hyper-util",
|
2023-07-20 22:53:03 +00:00
|
|
|
"hyperlocal",
|
|
|
|
"log",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2023-07-20 22:53:03 +00:00
|
|
|
"serde",
|
|
|
|
"serde_derive",
|
|
|
|
"serde_json",
|
2023-10-23 10:59:38 +00:00
|
|
|
"serde_repr",
|
2023-07-20 22:53:03 +00:00
|
|
|
"serde_urlencoded",
|
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
"tokio-util",
|
2024-09-06 03:31:45 +00:00
|
|
|
"tower-service",
|
2023-07-20 22:53:03 +00:00
|
|
|
"url",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bollard-stubs"
|
2024-09-06 03:31:45 +00:00
|
|
|
version = "1.45.0-rc.26.0.1"
|
2023-07-20 22:53:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-06 03:31:45 +00:00
|
|
|
checksum = "6d7c5415e3a6bc6d3e99eff6268e488fd4ee25e7b28c10f08fa6760bd9de16e4"
|
2023-07-20 22:53:03 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
2023-10-23 10:59:38 +00:00
|
|
|
"serde_repr",
|
2023-07-20 22:53:03 +00:00
|
|
|
"serde_with",
|
|
|
|
]
|
|
|
|
|
2023-11-25 09:01:11 +00:00
|
|
|
[[package]]
|
|
|
|
name = "borsh"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.5.0"
|
2023-11-25 09:01:11 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "dbe5b10e214954177fb1dc9fbd20a1a2608fe99e6c832033bdc7cea287a20d77"
|
2023-11-25 09:01:11 +00:00
|
|
|
dependencies = [
|
|
|
|
"borsh-derive",
|
|
|
|
"cfg_aliases",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "borsh-derive"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "1.5.1"
|
2023-11-25 09:01:11 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "c3ef8005764f53cd4dca619f5bf64cafd4664dada50ece25e4d81de54c80cc0b"
|
2023-11-25 09:01:11 +00:00
|
|
|
dependencies = [
|
|
|
|
"once_cell",
|
2024-09-05 21:03:23 +00:00
|
|
|
"proc-macro-crate 3.2.0",
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-11-25 09:01:11 +00:00
|
|
|
"syn_derive",
|
|
|
|
]
|
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bounded-collections"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.1.9"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "ca548b6163b872067dc5eb82fd130c56881435e30367d2073594a3d9744120dd"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-03-06 12:39:43 +00:00
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
2022-12-07 22:56:53 +00:00
|
|
|
]
|
|
|
|
|
2023-07-28 03:38:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bs58"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "0.5.1"
|
2023-07-28 03:38:04 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "bf88ba1141d185c399bee5288d850d63b8369520c1eafc32a0430b5b6c287bf4"
|
2023-07-28 03:38:04 +00:00
|
|
|
dependencies = [
|
|
|
|
"tinyvec",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bstr"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.10.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "40723b8fb387abc38f4f4a37c09073622e41dd12327033091ef8950659e6dc0c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
2023-01-08 14:10:17 +00:00
|
|
|
"serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "build-helper"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bdce191bf3fa4995ce948c8c83b4640a1745457a149e73c6db75b4ffe36aad5f"
|
|
|
|
dependencies = [
|
|
|
|
"semver 0.6.0",
|
|
|
|
]
|
|
|
|
|
2024-09-15 02:44:16 +00:00
|
|
|
[[package]]
|
|
|
|
name = "build-solidity-contracts"
|
2024-09-15 04:57:43 +00:00
|
|
|
version = "0.1.1"
|
2024-09-15 02:44:16 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bumpalo"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "3.16.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "79296716171880943b8470b5f8d03aa55eb2e645a4874bdbb28adb49162e012c"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "byte-slice-cast"
|
2022-11-04 12:07:37 +00:00
|
|
|
version = "1.2.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-11-04 12:07:37 +00:00
|
|
|
checksum = "c3ac9f8b63eca6fd385229b3675f6cc0dc5c8a5c8a54a59d4f52ffd670d87b0c"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "bytemuck"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.17.1"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "773d90827bc3feecfb67fab12e24de0749aad83c74b9504ecde46237b5cd24e2"
|
2023-03-06 12:39:43 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "byteorder"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "1.5.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "1fd0f2584146f6f2ef48085050886acf353beff7305ebd1ae69500e27c67f64b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bytes"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.7.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "8318a53db07bb3f8dca91a600466bdb3f2eaadeedfdbcf02e1accbad9271ba50"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "bzip2-sys"
|
|
|
|
version = "0.1.11+1.0.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "736a955f3fa7875102d57c82b8cac37ec45224a07fd32d58f9f7a186b6cd4cdc"
|
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"libc",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"pkg-config",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "c-kzg"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.3"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "f0307f72feab3300336fb803a57134159f6e20139af1357f36c54cb90d8e8928"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"blst",
|
|
|
|
"cc",
|
|
|
|
"glob",
|
|
|
|
"hex",
|
|
|
|
"libc",
|
2024-09-05 21:03:23 +00:00
|
|
|
"once_cell",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "camino"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.1.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "8b96ec4966b5813e2c0507c1f86115c8c5abaadc3980879c3424042a02fd1ad3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cargo-platform"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "0.1.8"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "24b1f0365a6c6bb4020cd05806fd0d33c44d38046b8bd7f0e40814b9763cabfc"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cargo_metadata"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.17.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "e7daec1a2a2129eeba1644b220b4647ec537b0b5d4bfd6876fcc5a540056b592"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"camino",
|
|
|
|
"cargo-platform",
|
2024-05-21 10:09:04 +00:00
|
|
|
"semver 1.0.23",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2022-11-04 12:07:37 +00:00
|
|
|
"thiserror",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cc"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.1.16"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "e9d013ecb737093c0e86b151a7b837993cf9ec6c502946cfb44bedc392421e0b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-05-21 12:07:32 +00:00
|
|
|
"jobserver",
|
2023-08-06 06:36:16 +00:00
|
|
|
"libc",
|
2024-09-05 21:03:23 +00:00
|
|
|
"shlex",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cexpr"
|
|
|
|
version = "0.6.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6fac387a98bb7c37292057cffc56d62ecb629900026402633ae9160df93a8766"
|
|
|
|
dependencies = [
|
|
|
|
"nom",
|
|
|
|
]
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "cfg-expr"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
version = "0.15.8"
|
2022-09-29 18:33:09 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
checksum = "d067ad48b8650848b989a59a86c6c36a995d02d2bf778d45c3c5d57bc2718f02"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-09-29 18:33:09 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "cfg-if"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "baf1de4339761588bc0619e3cbc0120ee582ebb74b53b4efbf79117bd2da40fd"
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "cfg_aliases"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fd16c4719339c4530435d38e511904438d07cce7950afa3718a84ac36c10e89e"
|
|
|
|
|
2022-10-29 08:54:42 +00:00
|
|
|
[[package]]
|
|
|
|
name = "chacha20"
|
2023-04-08 08:44:28 +00:00
|
|
|
version = "0.9.1"
|
2022-10-29 08:54:42 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-08 08:44:28 +00:00
|
|
|
checksum = "c3613f74bd2eac03dad61bd53dbe620703d4371614fe0bc3b9f04dd36fe4e818"
|
2022-10-29 08:54:42 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-11-12 05:40:32 +00:00
|
|
|
"cipher",
|
2022-10-29 08:54:42 +00:00
|
|
|
"cpufeatures",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "chacha20poly1305"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.10.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "10cd79432192d1c0f4e1a0fef9527696cc039165d729fb41b3f4f4f354c2dc35"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"aead",
|
2023-11-12 05:40:32 +00:00
|
|
|
"chacha20",
|
|
|
|
"cipher",
|
2022-07-16 21:49:35 +00:00
|
|
|
"poly1305",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "chrono"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
version = "0.4.38"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
checksum = "a21f936df1771bf62b77f047b726c4625ff2e8aa607c01ec06e5a05bd8463401"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"android-tzdata",
|
2022-08-16 07:44:32 +00:00
|
|
|
"iana-time-zone",
|
|
|
|
"js-sys",
|
2022-07-16 21:49:35 +00:00
|
|
|
"num-traits",
|
2023-10-23 10:59:38 +00:00
|
|
|
"serde",
|
2022-08-16 07:44:32 +00:00
|
|
|
"wasm-bindgen",
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows-targets 0.52.6",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cid"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.10.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "fd94671561e36e4e7de75f753f577edafb0e7c05d6e4547229fdf7938fbcd2c3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-05-21 09:27:01 +00:00
|
|
|
"core2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"multibase",
|
2023-07-28 03:38:04 +00:00
|
|
|
"multihash 0.18.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
|
|
|
"unsigned-varint",
|
|
|
|
]
|
|
|
|
|
2022-10-29 08:54:42 +00:00
|
|
|
[[package]]
|
|
|
|
name = "cipher"
|
2023-03-11 09:49:05 +00:00
|
|
|
version = "0.4.4"
|
2022-10-29 08:54:42 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-11 09:49:05 +00:00
|
|
|
checksum = "773f3b9af64447d2ce9850330c473515014aa235e6a783b02db81ff39e4a3dad"
|
2022-10-29 08:54:42 +00:00
|
|
|
dependencies = [
|
|
|
|
"crypto-common",
|
|
|
|
"inout",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ciphersuite"
|
2023-08-08 22:30:19 +00:00
|
|
|
version = "0.4.1"
|
2022-10-29 08:54:42 +00:00
|
|
|
dependencies = [
|
|
|
|
"dalek-ff-group",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"elliptic-curve",
|
|
|
|
"ff",
|
2022-12-25 07:50:10 +00:00
|
|
|
"ff-group-tests",
|
2023-03-02 15:04:18 +00:00
|
|
|
"flexible-transcript",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2022-12-25 07:50:10 +00:00
|
|
|
"hex",
|
2023-03-28 08:38:01 +00:00
|
|
|
"k256",
|
2022-10-29 08:54:42 +00:00
|
|
|
"minimal-ed448",
|
2023-07-28 03:38:04 +00:00
|
|
|
"p256",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-10-29 08:54:42 +00:00
|
|
|
"sha3",
|
2023-04-22 08:38:47 +00:00
|
|
|
"std-shims",
|
2022-10-29 08:54:42 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "clang-sys"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "1.8.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "0b023947811758c97c59bf9d1c188fd619ad4718dcaa767947df1cadb14f39f4"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"glob",
|
|
|
|
"libc",
|
2022-10-20 05:05:36 +00:00
|
|
|
"libloading",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "clap"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "4.5.17"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "3e5a21b8495e732f1b3c364c9949b201ca7bae518c502c80256c96ad79eaf6ac"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
2023-03-31 06:34:52 +00:00
|
|
|
"clap_builder",
|
2023-06-22 10:25:30 +00:00
|
|
|
"clap_derive",
|
2023-03-31 06:34:52 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "clap_builder"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "4.5.17"
|
2023-03-31 06:34:52 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "8cf2dd12af7a047ad9d6da2b6b249759a22a7abc0f474c1dae1777afa4b21a73"
|
2023-03-31 06:34:52 +00:00
|
|
|
dependencies = [
|
|
|
|
"anstream",
|
|
|
|
"anstyle",
|
2023-06-22 10:25:30 +00:00
|
|
|
"clap_lex",
|
2022-10-20 05:05:36 +00:00
|
|
|
"strsim",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "clap_derive"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "4.5.13"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "501d359d5f3dcaf6ecdeee48833ae73ec6e42723a1e52419c79abf9507eec0a0"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.5.0",
|
2022-10-20 05:05:36 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-10-20 05:05:36 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "clap_lex"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.7.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "1462739cb27611015575c0c11df5df7601141071f07518d56fcc1be504cbec97"
|
2022-10-20 05:05:36 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "codespan-reporting"
|
|
|
|
version = "0.11.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3538270d33cc669650c4b093848450d380def10c331d38c768e34cac80576e6e"
|
|
|
|
dependencies = [
|
|
|
|
"termcolor",
|
|
|
|
"unicode-width",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-04-14 01:05:18 +00:00
|
|
|
[[package]]
|
|
|
|
name = "colorchoice"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.0.2"
|
2023-04-14 01:05:18 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "d3fd119d74b830634cea2a0f58bbd0d54540518a14397557951e79340abc28c0"
|
2023-04-14 01:05:18 +00:00
|
|
|
|
2022-11-11 04:59:20 +00:00
|
|
|
[[package]]
|
|
|
|
name = "concurrent-queue"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "2.5.0"
|
2022-11-11 04:59:20 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "4ca0197aee26d1ae37445ee532fefce43251d24cc7c166799f4d46817f1d3973"
|
2022-11-11 04:59:20 +00:00
|
|
|
dependencies = [
|
|
|
|
"crossbeam-utils",
|
|
|
|
]
|
|
|
|
|
2023-09-12 11:47:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "const-hex"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "1.12.0"
|
2023-09-12 11:47:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "94fb8a24a26d37e1ffd45343323dc9fe6654ceea44c12f2fcb3d7ac29e610bc6"
|
2023-09-12 11:47:03 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"cpufeatures",
|
|
|
|
"hex",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"proptest",
|
2023-09-12 11:47:03 +00:00
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "const-oid"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.9.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "c2459377285ad874054d797f3ccebf984978aa39129f6eafde5cdc8315b612f8"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-07-28 03:38:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "const-random"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "0.1.18"
|
2023-07-28 03:38:04 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "87e00182fe74b066627d63b85fd550ac2998d4b0bd86bfed477a0ae4c7c71359"
|
2023-07-28 03:38:04 +00:00
|
|
|
dependencies = [
|
|
|
|
"const-random-macro",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "const-random-macro"
|
2023-10-24 08:03:51 +00:00
|
|
|
version = "0.1.16"
|
2023-07-28 03:38:04 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-24 08:03:51 +00:00
|
|
|
checksum = "f9d839f2a20b0aee515dc581a6172f2321f96cab76c1a38a4c584a194955390e"
|
2023-07-28 03:38:04 +00:00
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"getrandom",
|
2023-07-28 03:38:04 +00:00
|
|
|
"once_cell",
|
|
|
|
"tiny-keccak",
|
|
|
|
]
|
|
|
|
|
2023-07-19 02:30:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "constant_time_eq"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.1"
|
2023-07-19 02:30:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "7c74b8349d32d297c9134b8c88677813a227df8f779daa29bfc29c183fe3dca6"
|
2023-07-19 02:30:55 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "convert_case"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6245d59a3e82a7fc217c5828a6692dbc6dfb63a0c8c90495621f7b9d79704a0e"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "core-foundation"
|
2023-12-03 05:04:59 +00:00
|
|
|
version = "0.9.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-03 05:04:59 +00:00
|
|
|
checksum = "91e195e091a93c46f7102ec7818a2aa394e1e1771c3ab4825963fa03e45afb8f"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "core-foundation-sys"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.7"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "773648b94d0e5d620f64f280777445740e61fe701025087ec8b57f45c791888b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "core2"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b49ba7ef1ad6107f8824dbe97de947cbaac53c44e7f9756a1fba0d37c1eec505"
|
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cpp_demangle"
|
|
|
|
version = "0.3.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "eeaa953eaad386a53111e47172c2fedba671e5684c8dd601a5f474f4f118710f"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cpufeatures"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.13"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "51e852e6dc9a5bed1fae92dd2375037bf2b768725bf3be87811edee3249d09ad"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-bforest"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "5a91a1ccf6fb772808742db2f51e2179f25b1ec559cbe39ea080c72ff61caf8f"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cranelift-entity",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-codegen"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "169db1a457791bff4fd1fc585bb5cc515609647e0420a7d5c98d7700c59c2d00"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"bumpalo",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cranelift-bforest",
|
|
|
|
"cranelift-codegen-meta",
|
|
|
|
"cranelift-codegen-shared",
|
2023-08-23 02:06:06 +00:00
|
|
|
"cranelift-control",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cranelift-entity",
|
|
|
|
"cranelift-isle",
|
2023-08-23 02:06:06 +00:00
|
|
|
"gimli 0.27.3",
|
2023-06-28 18:57:58 +00:00
|
|
|
"hashbrown 0.13.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"regalloc2",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"target-lexicon",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-codegen-meta"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "3486b93751ef19e6d6eef66d2c0e83ed3d2ba01da1919ed2747f2f7bd8ba3419"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cranelift-codegen-shared",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-codegen-shared"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2023-08-23 02:06:06 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "86a1205ab18e7cd25dc4eca5246e56b506ced3feb8d95a8d776195e48d2cd4ef"
|
2023-08-23 02:06:06 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-control"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "1b108cae0f724ddfdec1871a0dc193a607e0c2d960f083cfefaae8ccf655eff2"
|
2023-08-23 02:06:06 +00:00
|
|
|
dependencies = [
|
|
|
|
"arbitrary",
|
|
|
|
]
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-entity"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "720444006240622798665bfc6aa8178e2eed556da342fda62f659c5267c3c659"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-frontend"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "b7a94c4c5508b7407e125af9d5320694b7423322e59a4ac0d07919ae254347ca"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cranelift-codegen",
|
|
|
|
"log",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"target-lexicon",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-isle"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "ef1f888d0845dcd6be4d625b91d9d8308f3d95bed5c5d4072ce38e1917faa505"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-native"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "9ad5966da08f1e96a3ae63be49966a85c9b249fa465f8cf1b66469a82b1004a0"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cranelift-codegen",
|
|
|
|
"libc",
|
|
|
|
"target-lexicon",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cranelift-wasm"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "0.99.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "0d8635c88b424f1d232436f683a301143b36953cd98fc6f86f7bac862dfeb6f5"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cranelift-codegen",
|
|
|
|
"cranelift-entity",
|
|
|
|
"cranelift-frontend",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"itertools 0.10.5",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasmparser",
|
|
|
|
"wasmtime-types",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crc32fast"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.4.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "a97769d94ddab943e4510d138150169a2758b5ef3eb191a9ee688de3e23ef7b3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-deque"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "0.8.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "613f8cc01fe9cf1a3eb3d7f488fd2fa8388403e97039e2f73692932e291a770d"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"crossbeam-epoch",
|
|
|
|
"crossbeam-utils",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-epoch"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "0.9.18"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "5b82ac4a3c2ca9c3460964f020e1402edd5753411d7737aa39c3714ad1b5420e"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"crossbeam-utils",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crossbeam-utils"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.8.20"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "22ec99545bb0ed0ea7bb9b8e1e9122ea386ff8a48c0922e43f36d45ab09e0e80"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "crunchy"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7a81dae078cea95a014a339291cec439d2f232ebe854a9d672b796c6afafa9b7"
|
|
|
|
|
2023-03-17 19:31:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "crypto-bigint"
|
2023-11-20 04:52:32 +00:00
|
|
|
version = "0.5.5"
|
2023-03-17 19:31:04 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-20 04:52:32 +00:00
|
|
|
checksum = "0dc92fb57ca44df6db8059111ab3af99a63d5d0f8375d9972e319a379c6bab76"
|
2023-03-17 19:31:04 +00:00
|
|
|
dependencies = [
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-17 19:31:04 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "crypto-common"
|
2022-07-18 00:56:10 +00:00
|
|
|
version = "0.1.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-07-18 00:56:10 +00:00
|
|
|
checksum = "1bfb12502f3fc46cca1bb51ac28df9d618d813cdc3d2f25b9fe775a34af26bb3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2023-11-12 05:40:32 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"typenum",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ctr"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.9.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "0369ee1ad671834580515889b80f2ea915f23b8be8d0daa4bbaf2ac5c7590835"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-11-12 05:40:32 +00:00
|
|
|
"cipher",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "curve25519-dalek"
|
2024-06-19 16:39:47 +00:00
|
|
|
version = "4.1.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-19 16:39:47 +00:00
|
|
|
checksum = "97fb8b7c4503de7d6ae7b42ab72a5a59857b4c937ec27a3d4539dba95b5ab2be"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-12-21 04:12:26 +00:00
|
|
|
"cfg-if",
|
2023-08-17 05:25:50 +00:00
|
|
|
"cpufeatures",
|
|
|
|
"curve25519-dalek-derive",
|
|
|
|
"digest 0.10.7",
|
2022-12-21 04:12:26 +00:00
|
|
|
"fiat-crypto",
|
2023-09-12 12:42:55 +00:00
|
|
|
"group",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2024-09-05 21:03:23 +00:00
|
|
|
"rustc_version 0.4.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-08-17 05:25:50 +00:00
|
|
|
[[package]]
|
|
|
|
name = "curve25519-dalek-derive"
|
2023-11-06 12:19:55 +00:00
|
|
|
version = "0.1.1"
|
2023-08-17 05:25:50 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-06 12:19:55 +00:00
|
|
|
checksum = "f46882e17999c6cc590af592290432be3bce0428cb0d5f8b6715e4dc7b383eb3"
|
2023-08-17 05:25:50 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-08-17 05:25:50 +00:00
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "cxx"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.128"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "54ccead7d199d584d139148b04b4a368d1ec7556a1d9ea2548febb1b9d49f9a4"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"cxxbridge-flags",
|
|
|
|
"cxxbridge-macro",
|
|
|
|
"link-cplusplus",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cxx-build"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.128"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "c77953e99f01508f89f55c494bfa867171ef3a6c8cea03d26975368f2121a5c1"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"codespan-reporting",
|
|
|
|
"once_cell",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"scratch",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-10-20 05:05:36 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cxxbridge-flags"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.128"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "65777e06cc48f0cb0152024c77d6cf9e4bdb4408e7b48bea993d42fa0f5b02b6"
|
2022-10-20 05:05:36 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "cxxbridge-macro"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.128"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "98532a60dedaebc4848cb2cba5023337cc9ea3af16a5b062633fabfd9f18fb60"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-10-20 05:05:36 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "dalek-ff-group"
|
2023-09-12 14:02:20 +00:00
|
|
|
version = "0.4.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"crypto-bigint",
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"ff",
|
2022-12-24 20:09:09 +00:00
|
|
|
"ff-group-tests",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-28 08:43:10 +00:00
|
|
|
"rustversion",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
Utilize zeroize (#76)
* Apply Zeroize to nonces used in Bulletproofs
Also makes bit decomposition constant time for a given amount of
outputs.
* Fix nonce reuse for single-signer CLSAG
* Attach Zeroize to most structures in Monero, and ZOnDrop to anything with private data
* Zeroize private keys and nonces
* Merge prepare_outputs and prepare_transactions
* Ensure CLSAG is constant time
* Pass by borrow where needed, bug fixes
The past few commitments have been one in-progress chunk which I've
broken up as best read.
* Add Zeroize to FROST structs
Still needs to zeroize internally, yet next step. Not quite as
aggressive as Monero, partially due to the limitations of HashMaps,
partially due to less concern about metadata, yet does still delete a
few smaller items of metadata (group key, context string...).
* Remove Zeroize from most Monero multisig structs
These structs largely didn't have private data, just fields with private
data, yet those fields implemented ZeroizeOnDrop making them already
covered. While there is still traces of the transaction left in RAM,
fully purging that was never the intent.
* Use Zeroize within dleq
bitvec doesn't offer Zeroize, so a manual zeroing has been implemented.
* Use Zeroize for random_nonce
It isn't perfect, due to the inability to zeroize the digest, and due to
kp256 requiring a few transformations. It does the best it can though.
Does move the per-curve random_nonce to a provided one, which is allowed
as of https://github.com/cfrg/draft-irtf-cfrg-frost/pull/231.
* Use Zeroize on FROST keygen/signing
* Zeroize constant time multiexp.
* Correct when FROST keygen zeroizes
* Move the FROST keys Arc into FrostKeys
Reduces amount of instances in memory.
* Manually implement Debug for FrostCore to not leak the secret share
* Misc bug fixes
* clippy + multiexp test bug fixes
* Correct FROST key gen share summation
It leaked our own share for ourself.
* Fix cross-group DLEq tests
2022-08-03 08:25:18 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "dashmap"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "6.1.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "5041cc499144891f3790297212f32a74fb938e5136a14943f338ef9e0ae276cf"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2024-09-05 21:03:23 +00:00
|
|
|
"crossbeam-utils",
|
2024-05-21 10:09:04 +00:00
|
|
|
"hashbrown 0.14.5",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"lock_api",
|
|
|
|
"once_cell",
|
2024-05-21 12:07:32 +00:00
|
|
|
"parking_lot_core 0.9.10",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "data-encoding"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "2.6.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "e8566979429cf69b49a5c740c60791108e86440e8be149bbea4fe54d2c32d6e2"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "data-encoding-macro"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.1.15"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "f1559b6cba622276d6d63706db152618eeb15b89b3e4041446b05876e352e639"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"data-encoding",
|
|
|
|
"data-encoding-macro-internal",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "data-encoding-macro-internal"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.1.13"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "332d754c0af53bc87c108fed664d121ecf59207ec4196041f04d6ab9002ad33f"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"data-encoding",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "debugid"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bef552e6f588e446098f6ba40d89ac146c8c7b64aade83c051ee00bb5d2bc18d"
|
|
|
|
dependencies = [
|
2023-11-09 18:22:43 +00:00
|
|
|
"uuid",
|
2023-08-23 02:06:06 +00:00
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "der"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "0.7.9"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "f55bf8e7b65898637379c1b74eb1551107c8294ed26d855ceb9fd1a09cfc9bc0"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"const-oid",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "der-parser"
|
|
|
|
version = "8.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "dbd676fbbab537128ef0278adb5576cf363cff6aa22a7b24effe97347cfab61e"
|
|
|
|
dependencies = [
|
|
|
|
"asn1-rs",
|
|
|
|
"displaydoc",
|
|
|
|
"nom",
|
|
|
|
"num-bigint",
|
|
|
|
"num-traits",
|
|
|
|
"rusticata-macros",
|
|
|
|
]
|
|
|
|
|
2023-08-06 06:36:16 +00:00
|
|
|
[[package]]
|
|
|
|
name = "deranged"
|
2024-01-04 06:46:26 +00:00
|
|
|
version = "0.3.11"
|
2023-08-06 06:36:16 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-04 06:46:26 +00:00
|
|
|
checksum = "b42b6fa04a440b495c8b04d0e71b707c585f83cb9cb28cf8cd0d976c315e31b4"
|
2023-10-19 04:02:27 +00:00
|
|
|
dependencies = [
|
|
|
|
"powerfmt",
|
2023-10-23 10:59:38 +00:00
|
|
|
"serde",
|
2023-10-19 04:02:27 +00:00
|
|
|
]
|
2023-08-06 06:36:16 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "derivative"
|
|
|
|
version = "2.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fcc3dd5e9e9c0b295d6e1e4d811fb6f157d5ffd784b8d202fc62eac8035a770b"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
]
|
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "derive-syn-parse"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e79116f119dd1dba1abf1f3405f03b9b0e79a27a3883864bfebded8a3dc768cd"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2023-03-06 12:39:43 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "derive_more"
|
2024-06-19 16:39:47 +00:00
|
|
|
version = "0.99.18"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-19 16:39:47 +00:00
|
|
|
checksum = "5f33878137e4dafd7fa914ad4e259e18a4e8e532b9617a2d0150262bf53abfce"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"convert_case",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"rustc_version 0.4.1",
|
|
|
|
"syn 2.0.77",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "derive_more"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4a9b99b9cbbe49445b21764dc0625032a89b145a2642e67603e1c936f5458d05"
|
|
|
|
dependencies = [
|
|
|
|
"derive_more-impl",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "derive_more-impl"
|
|
|
|
version = "1.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cb7330aeadfbe296029522e6c40f315320aba36fc43a5b3632f3795348f3bd22"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "difflib"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6184e33543162437515c2e2b48714794e37845ec9851711914eec9d308f6ebe8"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "digest"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d3dd60d1080a57a05ab032377049e0591415d2b31afd7028356dbf3cc6dcb066"
|
|
|
|
dependencies = [
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "digest"
|
2023-06-22 10:25:30 +00:00
|
|
|
version = "0.10.7"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-22 10:25:30 +00:00
|
|
|
checksum = "9ed9a281f7bc9b7576e61468ba615a66a5c8cfdff42420a70aa82701a3b1e292"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-03-11 09:49:05 +00:00
|
|
|
"block-buffer 0.10.4",
|
2023-04-08 08:44:28 +00:00
|
|
|
"const-oid",
|
2022-07-16 21:49:35 +00:00
|
|
|
"crypto-common",
|
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
2022-11-15 04:24:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "digest_auth"
|
2023-05-10 11:34:07 +00:00
|
|
|
version = "0.3.1"
|
2022-11-15 04:24:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-05-10 11:34:07 +00:00
|
|
|
checksum = "3054f4e81d395e50822796c5e99ca522e6ba7be98947d6d4b0e5e61640bdb894"
|
2022-11-15 04:24:35 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-11-15 04:24:35 +00:00
|
|
|
"hex",
|
2023-05-10 11:34:07 +00:00
|
|
|
"md-5",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-11-15 04:24:35 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "directories"
|
2023-08-25 03:55:47 +00:00
|
|
|
version = "5.0.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-25 03:55:47 +00:00
|
|
|
checksum = "9a49173b84e034382284f27f1af4dcbbd231ffa358c0fe316541a7337f376a35"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"dirs-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "directories-next"
|
|
|
|
version = "2.0.0"
|
|
|
|
dependencies = [
|
2023-12-04 12:40:56 +00:00
|
|
|
"directories",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "dirs-sys"
|
2023-08-25 03:55:47 +00:00
|
|
|
version = "0.4.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-25 03:55:47 +00:00
|
|
|
checksum = "520f05a5cbd335fae5a99ff7a6ab8627577660ee5cfd6a94a6a929b52ff0321c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
2023-08-25 03:55:47 +00:00
|
|
|
"option-ext",
|
2022-07-16 21:49:35 +00:00
|
|
|
"redox_users",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "displaydoc"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.2.5"
|
2023-08-25 03:55:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "97369cbbc041bc366949bc74d34658d6cda5621039731c6310521892a3a20ae0"
|
2023-08-25 03:55:47 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-08-25 03:55:47 +00:00
|
|
|
]
|
|
|
|
|
2022-10-29 08:54:42 +00:00
|
|
|
[[package]]
|
|
|
|
name = "dkg"
|
2023-08-08 22:30:19 +00:00
|
|
|
version = "0.5.1"
|
2022-10-29 08:54:42 +00:00
|
|
|
dependencies = [
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"blake2",
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-11-12 05:40:32 +00:00
|
|
|
"chacha20",
|
2022-10-29 08:54:42 +00:00
|
|
|
"ciphersuite",
|
|
|
|
"dleq",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"ec-divisors",
|
|
|
|
"embedwards25519",
|
2022-10-29 08:54:42 +00:00
|
|
|
"flexible-transcript",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"generalized-bulletproofs",
|
|
|
|
"generalized-bulletproofs-circuit-abstraction",
|
|
|
|
"generalized-bulletproofs-ec-gadgets",
|
|
|
|
"generic-array 1.1.0",
|
2022-10-29 08:54:42 +00:00
|
|
|
"multiexp",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"pasta_curves",
|
|
|
|
"rand",
|
|
|
|
"rand_chacha",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-10-29 08:54:42 +00:00
|
|
|
"schnorr-signatures",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"secq256k1",
|
2023-05-13 03:24:47 +00:00
|
|
|
"std-shims",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"subtle",
|
2022-10-29 08:54:42 +00:00
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
2022-07-30 22:35:39 +00:00
|
|
|
name = "dleq"
|
2023-08-08 22:30:19 +00:00
|
|
|
version = "0.4.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"blake2",
|
|
|
|
"dalek-ff-group",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"ff",
|
2022-07-16 21:49:35 +00:00
|
|
|
"flexible-transcript",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2023-07-24 08:53:59 +00:00
|
|
|
"hex-literal",
|
2023-03-28 08:38:01 +00:00
|
|
|
"k256",
|
2022-07-16 21:49:35 +00:00
|
|
|
"multiexp",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-28 08:43:10 +00:00
|
|
|
"rustversion",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
Utilize zeroize (#76)
* Apply Zeroize to nonces used in Bulletproofs
Also makes bit decomposition constant time for a given amount of
outputs.
* Fix nonce reuse for single-signer CLSAG
* Attach Zeroize to most structures in Monero, and ZOnDrop to anything with private data
* Zeroize private keys and nonces
* Merge prepare_outputs and prepare_transactions
* Ensure CLSAG is constant time
* Pass by borrow where needed, bug fixes
The past few commitments have been one in-progress chunk which I've
broken up as best read.
* Add Zeroize to FROST structs
Still needs to zeroize internally, yet next step. Not quite as
aggressive as Monero, partially due to the limitations of HashMaps,
partially due to less concern about metadata, yet does still delete a
few smaller items of metadata (group key, context string...).
* Remove Zeroize from most Monero multisig structs
These structs largely didn't have private data, just fields with private
data, yet those fields implemented ZeroizeOnDrop making them already
covered. While there is still traces of the transaction left in RAM,
fully purging that was never the intent.
* Use Zeroize within dleq
bitvec doesn't offer Zeroize, so a manual zeroing has been implemented.
* Use Zeroize for random_nonce
It isn't perfect, due to the inability to zeroize the digest, and due to
kp256 requiring a few transformations. It does the best it can though.
Does move the per-curve random_nonce to a provided one, which is allowed
as of https://github.com/cfrg/draft-irtf-cfrg-frost/pull/231.
* Use Zeroize on FROST keygen/signing
* Zeroize constant time multiexp.
* Correct when FROST keygen zeroizes
* Move the FROST keys Arc into FrostKeys
Reduces amount of instances in memory.
* Manually implement Debug for FrostCore to not leak the secret share
* Misc bug fixes
* clippy + multiexp test bug fixes
* Correct FROST key gen share summation
It leaked our own share for ourself.
* Fix cross-group DLEq tests
2022-08-03 08:25:18 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-07-20 22:53:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "dockertest"
|
2024-09-06 03:31:45 +00:00
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b8648c989dfd460932144f0ce5c55ff35cf0de758f89ea20e3b3d0d3f5e1cce6"
|
2023-07-20 22:53:03 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"async-trait",
|
2024-09-06 03:31:45 +00:00
|
|
|
"base64 0.22.1",
|
2023-07-20 22:53:03 +00:00
|
|
|
"bollard",
|
2024-09-06 03:31:45 +00:00
|
|
|
"bytes",
|
2023-07-20 22:53:03 +00:00
|
|
|
"dyn-clone",
|
|
|
|
"futures",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-07-20 22:53:03 +00:00
|
|
|
"secrecy",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2024-09-06 03:31:45 +00:00
|
|
|
"strum 0.26.3",
|
2023-07-20 22:53:03 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "downcast"
|
|
|
|
version = "0.11.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1435fa1053d8b2fbbe9be7e97eca7f33d37b28409959813daefc1446a14247f1"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "dtoa"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "1.0.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "dcbb2bf8e87535c23f7a8a321e364ce21462d0ff10cb6407820e8e96dfff6653"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "dunce"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "92773504d58c093f6de2459af4af33faa518c13451eb8f2b5698ed3d36e7c813"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "dyn-clonable"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4e9232f0e607a262ceb9bd5141a3dfb3e4db6994b31989bbfd845878cba59fd4"
|
|
|
|
dependencies = [
|
|
|
|
"dyn-clonable-impl",
|
|
|
|
"dyn-clone",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "dyn-clonable-impl"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "558e40ea573c374cf53507fd240b7ee2f5477df7cfebdb97323ec61c719399c5"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "dyn-clone"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "1.0.17"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "0d6ef0072f8a535281e4876be788938b528e9a1d43900b82c2569af7da799125"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ec-divisors"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"dalek-ff-group",
|
|
|
|
"group",
|
|
|
|
"hex",
|
|
|
|
"pasta_curves",
|
|
|
|
"rand_core",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ecdsa"
|
2023-11-20 04:52:32 +00:00
|
|
|
version = "0.16.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-20 04:52:32 +00:00
|
|
|
checksum = "ee27f32b5c5292967d2d4a9d7f1e0b0aed2c15daded5a60300e4abb9d8020bca"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"der",
|
|
|
|
"digest 0.10.7",
|
|
|
|
"elliptic-curve",
|
|
|
|
"rfc6979",
|
2023-08-25 03:55:47 +00:00
|
|
|
"signature",
|
2023-07-28 03:38:04 +00:00
|
|
|
"spki",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ed25519"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "2.2.3"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "115531babc129696a58c64a4fef0a8bf9e9698629fb97e9e40767d235cfbcd53"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"pkcs8",
|
2023-08-25 03:55:47 +00:00
|
|
|
"signature",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ed25519-dalek"
|
2024-02-09 07:48:44 +00:00
|
|
|
version = "2.1.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-09 07:48:44 +00:00
|
|
|
checksum = "4a3daa8e81a3963a60642bcc1f90a670680bd4a77535faa384e9d1c79d620871"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2023-08-25 03:55:47 +00:00
|
|
|
"ed25519",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-11-16 19:18:00 +00:00
|
|
|
"subtle",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ed25519-zebra"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "4.0.3"
|
2022-09-29 18:33:09 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "7d9ce6874da5d4415896cd45ffbc4d1cfc0c4f9c079427bd870742c30f2f65a9"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2023-08-25 03:55:47 +00:00
|
|
|
"ed25519",
|
2024-05-21 10:09:04 +00:00
|
|
|
"hashbrown 0.14.5",
|
2022-09-29 18:33:09 +00:00
|
|
|
"hex",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-09-29 18:33:09 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "either"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.13.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "60b1af1c220855b6ceac025d3f6ecdd2b7c4894bfe9cd9bda4fbb4bc7c0d4cf0"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "elliptic-curve"
|
2023-11-20 04:52:32 +00:00
|
|
|
version = "0.13.8"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-20 04:52:32 +00:00
|
|
|
checksum = "b5e6043086bf7973472e0c7dff2142ea0b680d30e18d9cc40f267efbf222bd47"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"base16ct",
|
|
|
|
"crypto-bigint",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"ff",
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
|
|
|
"pkcs8",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-07-28 03:38:04 +00:00
|
|
|
"sec1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
2023-10-16 03:57:45 +00:00
|
|
|
"tap",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
[[package]]
|
|
|
|
name = "embedwards25519"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"blake2",
|
|
|
|
"ciphersuite",
|
|
|
|
"crypto-bigint",
|
|
|
|
"dalek-ff-group",
|
|
|
|
"ec-divisors",
|
|
|
|
"ff-group-tests",
|
|
|
|
"generalized-bulletproofs-ec-gadgets",
|
|
|
|
"generic-array 0.14.7",
|
|
|
|
"hex",
|
|
|
|
"hex-literal",
|
|
|
|
"rand_core",
|
|
|
|
"rustversion",
|
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "enum-as-inner"
|
2022-10-20 05:05:36 +00:00
|
|
|
version = "0.5.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-10-20 05:05:36 +00:00
|
|
|
checksum = "c9720bba047d567ffc8a3cba48bf19126600e249ab7f128e9233e6376976a116"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.4.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-10-19 04:27:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "enum-as-inner"
|
|
|
|
version = "0.6.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5ffccbb6966c05b32ef8fbac435df276c4ae4d3dc55a8cd0eb9745e6c12f546a"
|
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.4.1",
|
2023-10-19 04:27:21 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-10-19 04:27:21 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "env_logger"
|
2024-01-19 16:44:49 +00:00
|
|
|
version = "0.10.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-19 16:44:49 +00:00
|
|
|
checksum = "4cd405aab171cb85d6735e5c8d9db038c17d3ca007a4d2c25f337935c3d90580"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"humantime",
|
2023-01-08 14:10:17 +00:00
|
|
|
"is-terminal",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"regex",
|
|
|
|
"termcolor",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "environmental"
|
2022-12-07 22:56:53 +00:00
|
|
|
version = "1.1.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-12-07 22:56:53 +00:00
|
|
|
checksum = "e48c92028aaa870e83d51c64e5d4e0b6981b360c522198c23959f219a4e1b15b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-06-28 18:57:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "equivalent"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "1.0.1"
|
2023-06-28 18:57:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "5443807d6dff69373d433ab9ef5378ad8df50ca6298caf15de6e52e24aaf54d5"
|
2023-06-28 18:57:58 +00:00
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "errno"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.3.9"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "534c5cf6194dfab3db3242765c03bbe257cf92f22b38f6bc0c58d59108a820ba"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.52.0",
|
2023-03-25 04:45:33 +00:00
|
|
|
]
|
|
|
|
|
2024-09-15 04:41:16 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ethereum-schnorr-contract"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"alloy-core",
|
|
|
|
"alloy-node-bindings",
|
|
|
|
"alloy-provider",
|
|
|
|
"alloy-rpc-client",
|
|
|
|
"alloy-rpc-types-eth",
|
|
|
|
"alloy-simple-request-transport",
|
|
|
|
"alloy-sol-types",
|
|
|
|
"build-solidity-contracts",
|
|
|
|
"group",
|
|
|
|
"k256",
|
|
|
|
"rand_core",
|
|
|
|
"sha3",
|
|
|
|
"subtle",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ethereum-serai"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-consensus",
|
|
|
|
"alloy-core",
|
2024-05-10 17:33:56 +00:00
|
|
|
"alloy-network",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-node-bindings",
|
|
|
|
"alloy-provider",
|
|
|
|
"alloy-rpc-client",
|
2024-06-13 19:57:08 +00:00
|
|
|
"alloy-rpc-types-eth",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"alloy-simple-request-transport",
|
|
|
|
"alloy-sol-types",
|
2024-09-15 16:04:57 +00:00
|
|
|
"ethereum-schnorr-contract",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"flexible-transcript",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2023-03-28 08:38:01 +00:00
|
|
|
"k256",
|
2022-07-16 21:49:35 +00:00
|
|
|
"modular-frost",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2024-09-15 02:12:32 +00:00
|
|
|
"serai-processor-ethereum-contracts",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "event-listener"
|
2022-08-16 07:44:32 +00:00
|
|
|
version = "2.5.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-08-16 07:44:32 +00:00
|
|
|
checksum = "0206175f82b8d6bf6652ff7d71a1e27fd2e4efde587fd368662814d6ec1d9ce0"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-11-22 06:24:17 +00:00
|
|
|
[[package]]
|
|
|
|
name = "event-listener"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "5.3.1"
|
2023-11-22 06:24:17 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "6032be9bd27023a771701cc49f9f053c751055f71efb2e0ae5c15809093675ba"
|
2023-11-22 06:24:17 +00:00
|
|
|
dependencies = [
|
|
|
|
"concurrent-queue",
|
|
|
|
"parking",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2023-11-22 06:24:17 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "event-listener-strategy"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.5.2"
|
2023-11-22 06:24:17 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "0f214dc438f977e6d4e3500aaa277f5ad94ca83fbbd9b1a15713ce2344ccc5a1"
|
2023-11-22 06:24:17 +00:00
|
|
|
dependencies = [
|
2024-06-13 19:57:08 +00:00
|
|
|
"event-listener 5.3.1",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2023-11-22 06:24:17 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "exit-future"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e43f2f1833d64e33f15592464d6fdd70f349dda7b1a53088eb83cd94014008c5"
|
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "expander"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "2.0.0"
|
2023-03-26 12:43:01 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "5f86a749cf851891866c10515ef6c299b5c69661465e9c3bbe7e07a2b77fb0f7"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"blake2",
|
|
|
|
"fs-err",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "fallible-iterator"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4443176a9f2c162692bd3d352d745ef9413eec5782a80d8fd6f8a1ac692a07f7"
|
|
|
|
|
2023-07-24 08:54:13 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fastrand"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "2.1.1"
|
2023-07-24 08:54:13 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "e8c02a5121d4ea3eb16a80748c74f5549a5665e4c21333c6098f283870fbdea6"
|
2023-07-24 08:54:13 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fastrlp"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "139834ddba373bbdd213dffe02c8d110508dcf1726c2be27e8d1f7d7e1856418"
|
|
|
|
dependencies = [
|
|
|
|
"arrayvec",
|
|
|
|
"auto_impl",
|
|
|
|
"bytes",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fdlimit"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2c4c9e43643f5a3be4ca5b67d26b98031ff9db6806c3440ae32e02e3ceac3f1b"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ff"
|
|
|
|
version = "0.13.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ded41244b729663b1e574f1b4fb731469f69f79c17667b5d776b16cda0479449"
|
|
|
|
dependencies = [
|
2023-08-23 17:24:21 +00:00
|
|
|
"bitvec",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-25 04:45:33 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
2022-12-24 20:09:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ff-group-tests"
|
2023-08-08 22:18:59 +00:00
|
|
|
version = "0.13.1"
|
2022-12-24 20:09:09 +00:00
|
|
|
dependencies = [
|
2023-03-28 08:38:01 +00:00
|
|
|
"bls12_381",
|
2023-08-02 18:43:49 +00:00
|
|
|
"ff",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2023-03-28 08:38:01 +00:00
|
|
|
"k256",
|
2023-07-28 03:38:04 +00:00
|
|
|
"p256",
|
2023-03-28 08:38:01 +00:00
|
|
|
"pasta_curves",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-28 08:38:01 +00:00
|
|
|
"subtle",
|
2022-12-24 20:09:09 +00:00
|
|
|
]
|
|
|
|
|
2022-12-21 04:12:26 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fiat-crypto"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.2.9"
|
2022-12-21 04:12:26 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "28dea519a9695b9977216879a3ebfddf92f1c08c05d984f8996aecd6ecdc811d"
|
2022-12-21 04:12:26 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "file-per-thread-logger"
|
2023-08-23 02:06:06 +00:00
|
|
|
version = "0.2.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 02:06:06 +00:00
|
|
|
checksum = "8a3cc21c33af89af0930c8cae4ade5e6fdc17b5d2c97b3d2e2edb67a1cf683f3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"env_logger",
|
|
|
|
"log",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "filetime"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.25"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "35c0522e981e68cbfa8c3f978441a5f34b30b96e146b33cd3359176b50fe8586"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"libc",
|
2024-09-05 21:03:23 +00:00
|
|
|
"libredox",
|
|
|
|
"windows-sys 0.59.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "finality-grandpa"
|
2023-03-16 23:37:32 +00:00
|
|
|
version = "0.16.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-16 23:37:32 +00:00
|
|
|
checksum = "36530797b9bf31cd4ff126dcfee8170f86b00cfdcea3269d73133cc0415945c3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"log",
|
|
|
|
"num-traits",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"scale-info",
|
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fixed-hash"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "835c052cb0c08c1acf6ffd71c022172e18723949c8282f2b9f27efbc51e64534"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-10-20 05:05:36 +00:00
|
|
|
"rustc-hex",
|
|
|
|
"static_assertions",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fixedbitset"
|
|
|
|
version = "0.4.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0ce7134b9999ecaf8bcd65542e436736ef32ddca1b3e06094cb6ec5755203b80"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "flexible-transcript"
|
2023-08-08 22:18:59 +00:00
|
|
|
version = "0.3.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"blake2",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-04-08 08:44:28 +00:00
|
|
|
"merlin",
|
2023-03-28 08:43:10 +00:00
|
|
|
"rustversion",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-03-28 08:43:10 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "float-cmp"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "98de4bbd547a563b716d8dfa9aad1cb19bfab00f4fa09a6a4ed21dbcf44ce9c4"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fnv"
|
|
|
|
version = "1.0.7"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3f9eec918d3f24069decb9af1554cad7c880e2da24a9afd88aca000531ab82c1"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "fork-tree"
|
|
|
|
version = "3.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "form_urlencoded"
|
2023-12-06 09:51:40 +00:00
|
|
|
version = "1.2.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-06 09:51:40 +00:00
|
|
|
checksum = "e13624c2627564efccf4934284bdd98cbaa14e79b0b5a141218e507b3a823456"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"percent-encoding",
|
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fragile"
|
|
|
|
version = "2.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6c2141d6d6c8512188a7891b4b01590a45f6dac67afb4f255c4124dbb86d4eaa"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "frame-benchmarking"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
2023-03-06 12:39:43 +00:00
|
|
|
"frame-support-procedural",
|
2022-07-16 21:49:35 +00:00
|
|
|
"frame-system",
|
|
|
|
"linregress",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"paste",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-api",
|
|
|
|
"sp-application-crypto",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-runtime-interface",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-storage",
|
2023-03-06 12:39:43 +00:00
|
|
|
"static_assertions",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "frame-executive"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
2023-07-19 02:30:55 +00:00
|
|
|
"frame-try-runtime",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-tracing",
|
|
|
|
]
|
|
|
|
|
2023-07-19 02:30:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "frame-metadata"
|
|
|
|
version = "16.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "87cf1549fba25a6fcac22785b61698317d958e96cac72a59102ea45b9ae64692"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "frame-support"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"bitflags 1.3.2",
|
2023-03-26 12:43:01 +00:00
|
|
|
"environmental",
|
2023-11-28 07:29:50 +00:00
|
|
|
"frame-metadata",
|
2022-07-16 21:49:35 +00:00
|
|
|
"frame-support-procedural",
|
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"log",
|
2023-07-19 02:30:55 +00:00
|
|
|
"macro_magic",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"paste",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-api",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-arithmetic",
|
|
|
|
"sp-core",
|
|
|
|
"sp-core-hashing-proc-macro",
|
2023-06-28 18:57:58 +00:00
|
|
|
"sp-debug-derive",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-inherents",
|
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-staking",
|
|
|
|
"sp-state-machine",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-tracing",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-weights",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tt-call",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "frame-support-procedural"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
2022-09-29 18:33:09 +00:00
|
|
|
"cfg-expr",
|
2023-03-06 12:39:43 +00:00
|
|
|
"derive-syn-parse",
|
2023-07-19 02:30:55 +00:00
|
|
|
"expander",
|
2022-07-16 21:49:35 +00:00
|
|
|
"frame-support-procedural-tools",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"itertools 0.10.5",
|
2023-07-19 02:30:55 +00:00
|
|
|
"macro_magic",
|
2023-05-01 07:17:37 +00:00
|
|
|
"proc-macro-warning",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "frame-support-procedural-tools"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-support-procedural-tools-derive",
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "frame-support-procedural-tools-derive"
|
|
|
|
version = "3.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "frame-system"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"cfg-if",
|
2022-07-16 21:49:35 +00:00
|
|
|
"frame-support",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-version",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-weights",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "frame-system-rpc-runtime-api"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sp-api",
|
|
|
|
]
|
|
|
|
|
2023-07-19 02:30:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "frame-try-runtime"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-07-19 02:30:55 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sp-api",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-07-19 02:30:55 +00:00
|
|
|
]
|
|
|
|
|
2023-04-10 10:05:17 +00:00
|
|
|
[[package]]
|
|
|
|
name = "frost-schnorrkel"
|
2023-08-08 22:30:19 +00:00
|
|
|
version = "0.1.2"
|
2023-04-10 10:05:17 +00:00
|
|
|
dependencies = [
|
|
|
|
"ciphersuite",
|
|
|
|
"flexible-transcript",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2023-04-10 10:05:17 +00:00
|
|
|
"modular-frost",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-04-10 10:05:17 +00:00
|
|
|
"schnorr-signatures",
|
|
|
|
"schnorrkel",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fs-err"
|
2023-11-22 06:24:17 +00:00
|
|
|
version = "2.11.0"
|
2023-03-26 12:43:01 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-22 06:24:17 +00:00
|
|
|
checksum = "88a41f105fe1d5b6b34b2055e3dc59bb79b46b48b2040b9e6c7b4b5de097aa41"
|
2023-11-15 22:18:24 +00:00
|
|
|
dependencies = [
|
|
|
|
"autocfg",
|
|
|
|
]
|
2023-03-26 12:43:01 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fs2"
|
|
|
|
version = "0.4.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9564fc758e15025b46aa6643b1b77d047d1a56a1aea6e01002ac0c7026876213"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "funty"
|
|
|
|
version = "2.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e6d5a32815ae3f33302d95fdcb2ce17862f8c65363dcfd29360480ba1001fc9c"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "645c6916888f6cb6350d2550b80fb63e734897a8498abe35cfb732b6487804b0"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"futures-executor",
|
|
|
|
"futures-io",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-task",
|
|
|
|
"futures-util",
|
|
|
|
]
|
|
|
|
|
2023-10-19 04:27:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "futures-bounded"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8b07bbbe7d7e78809544c6f718d875627addc73a7c3582447abc052cd3dc67e0"
|
|
|
|
dependencies = [
|
|
|
|
"futures-timer",
|
|
|
|
"futures-util",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "futures-channel"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "eac8f7d7865dcb88bd4373ab671c8cf4508703796caa2b1985a9ca867b3fcb78"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-core"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "dfc6580bb841c5a68e9ef15c77ccc837b40a7504914d52e47b8b0e9bbda25a1d"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-executor"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "a576fc72ae164fca6b9db127eaa9a9dda0d61316034f33a0a0d4eda41f02b01d"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-core",
|
|
|
|
"futures-task",
|
|
|
|
"futures-util",
|
|
|
|
"num_cpus",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-io"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "a44623e20b9681a318efdd71c299b6b222ed6f231972bfe2f224ebad6311f0c1"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-lite"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "2.3.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "52527eb5074e35e9339c6b4e8d12600c7128b68fb25dcb9fa9dec18f7c25f3a5"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-core",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-macro"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "87750cf4b7a4c0625b1529e4c543c2182106e4dedc60a2a6455e00d212c489ac"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-rustls"
|
2023-08-25 03:55:47 +00:00
|
|
|
version = "0.24.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-25 03:55:47 +00:00
|
|
|
checksum = "35bd3cf68c183738046838e300353e4716c674dc5e56890de4826801a6622a28"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-io",
|
2024-05-21 10:09:04 +00:00
|
|
|
"rustls 0.21.12",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-sink"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "9fb8e00e87438d937621c1c6269e53f536c14d3fbd6a042bb24879e57d474fb5"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-task"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "38d84fa142264698cdce1a9f9172cf383a0c82de1bddcf3092901442c4097004"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-08-08 19:12:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "futures-ticker"
|
|
|
|
version = "0.0.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9763058047f713632a52e916cc7f6a4b3fc6e9fc1ff8c5b1dc49e5a89041682e"
|
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"instant",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "futures-timer"
|
2024-02-25 23:37:15 +00:00
|
|
|
version = "3.0.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-25 23:37:15 +00:00
|
|
|
checksum = "f288b0a4f20f9a56b5d1da57e2227c661b7b16168e2f72365f57b63326e29b24"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "futures-util"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "3d6401deb83407ab3da39eba7e33987a73c3df0c82b4bb5813ee871c19c41d48"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"futures-io",
|
|
|
|
"futures-macro",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-task",
|
|
|
|
"memchr",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pin-utils",
|
|
|
|
"slab",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "futures-utils-wasm"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "42012b0f064e01aa58b545fe3727f90f7dd4020f4a3ea735b50344965f5a57e9"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fxhash"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c31b6d751ae2c7f11320402d34e41349dd1016f8d5d45e48c4312bc8625af50c"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
]
|
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "fxprof-processed-profile"
|
|
|
|
version = "0.6.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "27d12c0aed7f1e24276a241aadc4cb8ea9f83000f34bc062b7cc2d51e3b0fabd"
|
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
2023-08-23 02:06:06 +00:00
|
|
|
"debugid",
|
|
|
|
"fxhash",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
]
|
|
|
|
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
[[package]]
|
|
|
|
name = "generalized-bulletproofs"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"blake2",
|
|
|
|
"ciphersuite",
|
|
|
|
"flexible-transcript",
|
|
|
|
"multiexp",
|
|
|
|
"rand_core",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "generalized-bulletproofs-circuit-abstraction"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ciphersuite",
|
|
|
|
"generalized-bulletproofs",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "generalized-bulletproofs-ec-gadgets"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ciphersuite",
|
|
|
|
"generalized-bulletproofs-circuit-abstraction",
|
|
|
|
"generic-array 1.1.0",
|
|
|
|
]
|
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "generator"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.8.1"
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "186014d53bc231d0090ef8d6f03e0920c54d85a5ed22f4f2f74315ec56cf83fb"
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
2024-05-21 12:07:32 +00:00
|
|
|
"cfg-if",
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
"libc",
|
|
|
|
"log",
|
|
|
|
"rustversion",
|
2024-05-21 12:07:32 +00:00
|
|
|
"windows 0.54.0",
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "generic-array"
|
2023-03-31 06:34:52 +00:00
|
|
|
version = "0.14.7"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-31 06:34:52 +00:00
|
|
|
checksum = "85649ca51fd72272d7821adaf274ad91c288277713d9c18820d8499a7ff69e9a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"typenum",
|
|
|
|
"version_check",
|
2023-03-25 04:45:33 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-10-29 13:07:14 +00:00
|
|
|
[[package]]
|
|
|
|
name = "generic-array"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.1.0"
|
2023-10-29 13:07:14 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "96512db27971c2c3eece70a1e106fbe6c87760234e31e8f7e5634912fe52794a"
|
2023-10-29 13:07:14 +00:00
|
|
|
dependencies = [
|
|
|
|
"typenum",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "getrandom"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.2.15"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "c4567c8db10ae91089c99af84c68c38da3ec2f087c3f82960bcdbf3656b6f4d7"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"libc",
|
2023-10-16 19:07:39 +00:00
|
|
|
"wasi",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2024-05-21 12:07:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "getrandom_or_panic"
|
|
|
|
version = "0.0.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6ea1015b5a70616b688dc230cfe50c8af89d972cb132d5a622814d29773b10b9"
|
|
|
|
dependencies = [
|
|
|
|
"rand",
|
|
|
|
"rand_core",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ghash"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "0.5.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "f0d8a4362ccb29cb0b265253fb0a2728f592895ee6854fd9bc13f2ffda266ff1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-04-08 08:44:28 +00:00
|
|
|
"opaque-debug",
|
2023-07-28 03:38:04 +00:00
|
|
|
"polyval",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "gimli"
|
2023-06-28 18:57:58 +00:00
|
|
|
version = "0.27.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-28 18:57:58 +00:00
|
|
|
checksum = "b6c80984affa11d98d1b88b66ac8853f143217b399d3c74116778ff8fdb4ed2e"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"fallible-iterator",
|
2023-06-28 18:57:58 +00:00
|
|
|
"indexmap 1.9.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"stable_deref_trait",
|
|
|
|
]
|
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "gimli"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.29.0"
|
2023-08-23 02:06:06 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "40ecd4077b5ae9fd2e9e169b102c6c330d0605168eb0e8bf79952b256dbefffd"
|
2023-08-23 02:06:06 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "glob"
|
2023-01-08 14:10:17 +00:00
|
|
|
version = "0.3.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-01-08 14:10:17 +00:00
|
|
|
checksum = "d2fabcfbdc87f4758337ca535fb41a6d701b65693ce38287d856d1674551ec9b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "globset"
|
2023-11-28 07:29:50 +00:00
|
|
|
version = "0.4.14"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-28 07:29:50 +00:00
|
|
|
checksum = "57da3b9b5b85bd66f31093f8c408b90a74431672542466497dcbdfdc02034be1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-19 02:30:55 +00:00
|
|
|
"aho-corasick",
|
2022-07-16 21:49:35 +00:00
|
|
|
"bstr",
|
|
|
|
"log",
|
2024-06-13 19:57:08 +00:00
|
|
|
"regex-automata 0.4.7",
|
|
|
|
"regex-syntax 0.8.4",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "group"
|
|
|
|
version = "0.13.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f0f9ef7462f7c099f518d754361858f86d8a07af53ba9af0fe635bbccb151a63"
|
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"ff",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "h2"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "0.3.26"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "81fe527a889e1532da5c525686d96d4c2e74cdd345badf8dfef9f6b39dd5f5e8"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"fnv",
|
|
|
|
"futures-core",
|
|
|
|
"futures-sink",
|
|
|
|
"futures-util",
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"slab",
|
|
|
|
"tokio",
|
|
|
|
"tokio-util",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hash-db"
|
2023-03-26 12:43:01 +00:00
|
|
|
version = "0.16.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-26 12:43:01 +00:00
|
|
|
checksum = "8e7d7786361d7425ae2fe4f9e407eb0efaa0840f5212d109cc018c40c35c6ab4"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hash256-std-hasher"
|
|
|
|
version = "0.15.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "92c171d55b98633f4ed3860808f004099b36c1cc29c42cfc53aa8591b21efcf2"
|
|
|
|
dependencies = [
|
|
|
|
"crunchy",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hashbrown"
|
2022-07-18 00:56:10 +00:00
|
|
|
version = "0.12.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-07-18 00:56:10 +00:00
|
|
|
checksum = "8a9ee70c43aaf417c914396645a0fa852624801b24ebb7ae78fe8272889ac888"
|
2023-03-06 12:39:43 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hashbrown"
|
|
|
|
version = "0.13.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "43a3c133739dddd0d2990f9a4bdf8eb4b21ef50e4851ca85ab661199821d510e"
|
|
|
|
dependencies = [
|
2023-08-22 02:58:45 +00:00
|
|
|
"ahash",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-06-28 18:57:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hashbrown"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.14.5"
|
2023-06-28 18:57:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "e5274423e17b7c9fc20b6e7e208532f9b19825d82dfd615708b70edd83df41f1"
|
2023-06-29 01:16:33 +00:00
|
|
|
dependencies = [
|
2023-08-22 02:58:45 +00:00
|
|
|
"ahash",
|
2023-06-29 01:16:33 +00:00
|
|
|
"allocator-api2",
|
|
|
|
]
|
2023-06-28 18:57:58 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
name = "heck"
|
|
|
|
version = "0.4.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
checksum = "95505c38b4572b2d910cecb0281560f54b440a19336cbbcb27bf6ce6adc6f5a8"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "heck"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
version = "0.5.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
checksum = "2304e00983f87ffb38b55b444b5e3b60a884b5d30c0fca7d82fe33449bbe55ea"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hermit-abi"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "0.3.9"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "d231dfb89cfffdbc30e7fc41579ed6066ad03abda9e567ccafae602b97ec5024"
|
2023-03-06 12:39:43 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hex"
|
|
|
|
version = "0.4.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7f24254aa9a54b5c858eaee2f5bccdb46aaf0e486a595ed5fd8f86ba55232a70"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-10-30 08:45:20 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hex-conservative"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.2.1"
|
2023-10-30 08:45:20 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "5313b072ce3c597065a808dbf612c4c8e8590bdbf8b579508bf7a762c5eae6cd"
|
2023-10-30 08:45:20 +00:00
|
|
|
dependencies = [
|
2024-05-21 09:27:01 +00:00
|
|
|
"arrayvec",
|
2023-10-30 08:45:20 +00:00
|
|
|
]
|
|
|
|
|
2023-04-09 06:31:10 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hex-literal"
|
|
|
|
version = "0.4.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6fe2267d4ed49bc07b63801559be28c718ea06c4738b7a03c94df7386d2cde46"
|
|
|
|
|
2023-08-08 19:12:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hex_fmt"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b07f60793ff0a4d9cef0f18e63b5357e06209987153a64648c972c1e5aff336f"
|
|
|
|
|
2023-04-09 06:31:10 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hex_lit"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3011d1213f159867b13cfd6ac92d2cd5f1345762c63be3554e84092d85a50bbd"
|
|
|
|
|
2023-10-16 19:07:39 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hkdf"
|
2023-12-15 05:54:39 +00:00
|
|
|
version = "0.12.4"
|
2023-10-16 19:07:39 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-15 05:54:39 +00:00
|
|
|
checksum = "7b5f8eb2ad728638ea2c7d47a21db23b7b58a72ed6a38256b8a1849f15fbbdf7"
|
2023-10-16 19:07:39 +00:00
|
|
|
dependencies = [
|
|
|
|
"hmac",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hmac"
|
|
|
|
version = "0.12.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6c49c37c09c17a53d937dfbb742eb3a961d65a994e6bcdcf37e7399d0cc8ab5e"
|
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "home"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.5.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "e3d1354bf6b7235cb4a0576c2619fd4ed18183f689b12b006a0ee7329eeff9a5"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-12-30 07:36:51 +00:00
|
|
|
"windows-sys 0.52.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hostname"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3c731c3e10504cc8ed35cfe2f1db4c9274c3d35fa486e3b31df46f068ef3e867"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"match_cfg",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "http"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "0.2.12"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "601cbb57e577e2f5ef5be8e7b83f0f63994f25aa94d673e54a92d5c516d101f1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"fnv",
|
2022-10-20 05:05:36 +00:00
|
|
|
"itoa",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2024-01-17 00:32:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "http"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "1.1.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "21b9ddb458710bc376481b842f5da65cdf31522de232c1ca8146abce2a358258"
|
2024-01-17 00:32:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"fnv",
|
|
|
|
"itoa",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "http-body"
|
2023-12-15 05:54:39 +00:00
|
|
|
version = "0.4.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-15 05:54:39 +00:00
|
|
|
checksum = "7ceab25649e9960c0311ea418d17bee82c0dcec1bd053b5f9a66e265a693bed2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2024-01-17 00:32:30 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "http-body"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.0.1"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "1efedce1fb8e6913f23e0c92de8e62cd5b772a67e7b3946df930a62566c93184"
|
2024-01-17 00:32:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
2024-03-08 04:21:15 +00:00
|
|
|
"http 1.1.0",
|
2024-01-17 00:32:30 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "http-body-util"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.1.2"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "793429d76616a256bcb62c2a2ec2bed781c8307e797e2598c50010f2bee2544f"
|
2024-01-17 00:32:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
2024-06-13 19:57:08 +00:00
|
|
|
"futures-util",
|
2024-03-08 04:21:15 +00:00
|
|
|
"http 1.1.0",
|
2024-07-15 00:27:36 +00:00
|
|
|
"http-body 1.0.1",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-01-04 08:17:36 +00:00
|
|
|
name = "http-range-header"
|
2023-07-24 08:54:13 +00:00
|
|
|
version = "0.3.1"
|
2023-01-04 08:17:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-24 08:54:13 +00:00
|
|
|
checksum = "add0ab9360ddbd88cfeb3bd9574a1d85cfdfa14db10b3e21d3700dbc4328758f"
|
2023-01-04 08:17:36 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "httparse"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.9.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "0fcc0b4a115bf80b728eb8ea024ad5bd707b615bfed49e0665b6e0f86fd082d9"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "httpdate"
|
2023-08-15 09:39:23 +00:00
|
|
|
version = "1.0.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-15 09:39:23 +00:00
|
|
|
checksum = "df3b46402a9d5adb4c86a0cf463f42e19994e3ee891101b1841f30a545cb49a9"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "humantime"
|
|
|
|
version = "2.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9a3a5bfb195931eeb336b2a7b4d761daec841b97f947d34394601737a7bba5e4"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hyper"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.14.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "a152ddd61dfaec7273fe8419ab357f33aee0d914c5f4efbf0d96fa749eea5ec9"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures-channel",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"h2",
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2024-01-17 00:32:30 +00:00
|
|
|
"http-body 0.4.6",
|
2022-07-16 21:49:35 +00:00
|
|
|
"httparse",
|
|
|
|
"httpdate",
|
2022-10-20 05:05:36 +00:00
|
|
|
"itoa",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2024-09-06 03:31:45 +00:00
|
|
|
"socket2 0.5.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tokio",
|
|
|
|
"tower-service",
|
|
|
|
"tracing",
|
|
|
|
"want",
|
|
|
|
]
|
|
|
|
|
2024-01-17 00:32:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hyper"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.4.1"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "50dfd22e0e76d0f662d429a5f80fcaf3855009297eab6a0a9f8543834744ba05"
|
2024-01-17 00:32:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures-channel",
|
|
|
|
"futures-util",
|
2024-03-08 04:21:15 +00:00
|
|
|
"http 1.1.0",
|
2024-07-15 00:27:36 +00:00
|
|
|
"http-body 1.0.1",
|
2024-01-17 00:32:30 +00:00
|
|
|
"httparse",
|
2024-09-06 03:31:45 +00:00
|
|
|
"httpdate",
|
2024-01-17 00:32:30 +00:00
|
|
|
"itoa",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2024-02-25 23:37:15 +00:00
|
|
|
"smallvec",
|
2024-01-17 00:32:30 +00:00
|
|
|
"tokio",
|
|
|
|
"want",
|
|
|
|
]
|
|
|
|
|
2024-09-06 03:31:45 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hyper-named-pipe"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "73b7d8abf35697b81a825e386fc151e0d503e8cb5fcb93cc8669c376dfd6f278"
|
|
|
|
dependencies = [
|
|
|
|
"hex",
|
|
|
|
"hyper 1.4.1",
|
|
|
|
"hyper-util",
|
|
|
|
"pin-project-lite",
|
|
|
|
"tokio",
|
|
|
|
"tower-service",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
2023-06-22 10:25:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hyper-rustls"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.27.3"
|
2023-06-22 10:25:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "08afdbb5c31130e3034af566421053ab03787c640246a446327f550d11bcb333"
|
2023-06-22 10:25:30 +00:00
|
|
|
dependencies = [
|
2023-07-04 17:20:59 +00:00
|
|
|
"futures-util",
|
2024-03-08 04:21:15 +00:00
|
|
|
"http 1.1.0",
|
2024-07-15 00:27:36 +00:00
|
|
|
"hyper 1.4.1",
|
2024-01-17 00:32:30 +00:00
|
|
|
"hyper-util",
|
2024-08-01 08:06:09 +00:00
|
|
|
"rustls 0.23.12",
|
2023-07-19 02:30:55 +00:00
|
|
|
"rustls-native-certs",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-pki-types",
|
2023-06-22 10:25:30 +00:00
|
|
|
"tokio",
|
2023-08-23 17:18:51 +00:00
|
|
|
"tokio-rustls",
|
2024-01-17 00:32:30 +00:00
|
|
|
"tower-service",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "hyper-util"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.7"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "cde7055719c54e36e95e8719f95883f22072a48ede39db7fc17a4e1d5281e9b9"
|
2024-01-17 00:32:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures-channel",
|
|
|
|
"futures-util",
|
2024-03-08 04:21:15 +00:00
|
|
|
"http 1.1.0",
|
2024-07-15 00:27:36 +00:00
|
|
|
"http-body 1.0.1",
|
|
|
|
"hyper 1.4.1",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2024-05-21 10:09:04 +00:00
|
|
|
"socket2 0.5.7",
|
2024-01-17 00:32:30 +00:00
|
|
|
"tokio",
|
|
|
|
"tower",
|
|
|
|
"tower-service",
|
|
|
|
"tracing",
|
2023-06-22 10:25:30 +00:00
|
|
|
]
|
|
|
|
|
2023-07-20 22:53:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "hyperlocal"
|
2024-09-06 03:31:45 +00:00
|
|
|
version = "0.9.1"
|
2023-07-20 22:53:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-06 03:31:45 +00:00
|
|
|
checksum = "986c5ce3b994526b3cd75578e62554abd09f0899d6206de48b3e96ab34ccc8c7"
|
2023-07-20 22:53:03 +00:00
|
|
|
dependencies = [
|
|
|
|
"hex",
|
2024-09-06 03:31:45 +00:00
|
|
|
"http-body-util",
|
|
|
|
"hyper 1.4.1",
|
|
|
|
"hyper-util",
|
|
|
|
"pin-project-lite",
|
2023-07-20 22:53:03 +00:00
|
|
|
"tokio",
|
2024-09-06 03:31:45 +00:00
|
|
|
"tower-service",
|
2023-07-20 22:53:03 +00:00
|
|
|
]
|
|
|
|
|
2022-08-16 07:44:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "iana-time-zone"
|
2024-02-04 06:13:48 +00:00
|
|
|
version = "0.1.60"
|
2022-08-16 07:44:32 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-04 06:13:48 +00:00
|
|
|
checksum = "e7ffbb5a1b541ea2561f8c41c087286cc091e21e556a4f09a8f6cbf17b69b141"
|
2022-08-16 07:44:32 +00:00
|
|
|
dependencies = [
|
|
|
|
"android_system_properties",
|
|
|
|
"core-foundation-sys",
|
2022-10-20 05:05:36 +00:00
|
|
|
"iana-time-zone-haiku",
|
2022-08-16 07:44:32 +00:00
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
2024-05-21 12:07:32 +00:00
|
|
|
"windows-core 0.51.1",
|
2022-08-16 07:44:32 +00:00
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "iana-time-zone-haiku"
|
2023-06-22 10:25:30 +00:00
|
|
|
version = "0.1.2"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-22 10:25:30 +00:00
|
|
|
checksum = "f31827a206f56af32e590ba56d5d2d085f558508192593743f16b2306495269f"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"cc",
|
2022-10-20 05:05:36 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "idna"
|
|
|
|
version = "0.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "418a0a6fab821475f634efe3ccc45c013f742efe03d853e8d3355d5cb850ecf8"
|
|
|
|
dependencies = [
|
|
|
|
"matches",
|
|
|
|
"unicode-bidi",
|
|
|
|
"unicode-normalization",
|
|
|
|
]
|
|
|
|
|
2022-09-18 19:30:38 +00:00
|
|
|
[[package]]
|
|
|
|
name = "idna"
|
2023-06-22 10:25:30 +00:00
|
|
|
version = "0.4.0"
|
2022-09-18 19:30:38 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-22 10:25:30 +00:00
|
|
|
checksum = "7d20d6b07bfbc108882d88ed8e37d39636dcc260e15e30c45e6ba089610b917c"
|
2022-09-18 19:30:38 +00:00
|
|
|
dependencies = [
|
|
|
|
"unicode-bidi",
|
|
|
|
"unicode-normalization",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "idna"
|
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "634d9b1461af396cad843f47fdba5597a4f9e6ddd4bfb6ff5d85028c25cb12f6"
|
|
|
|
dependencies = [
|
|
|
|
"unicode-bidi",
|
|
|
|
"unicode-normalization",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "if-addrs"
|
2023-11-22 06:24:17 +00:00
|
|
|
version = "0.10.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-22 06:24:17 +00:00
|
|
|
checksum = "cabb0019d51a643781ff15c9c8a3e5dedc365c47211270f4e8f82812fedd8f0a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "if-watch"
|
2023-11-22 06:24:17 +00:00
|
|
|
version = "3.2.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-22 06:24:17 +00:00
|
|
|
checksum = "d6b0422c86d7ce0e97169cc42e04ae643caf278874a7a3c87b8150a220dc7e1e"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-io",
|
|
|
|
"core-foundation",
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"if-addrs",
|
|
|
|
"ipnet",
|
|
|
|
"log",
|
|
|
|
"rtnetlink",
|
|
|
|
"system-configuration",
|
2023-01-16 15:42:31 +00:00
|
|
|
"tokio",
|
2023-10-12 22:37:16 +00:00
|
|
|
"windows 0.51.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-10-19 04:27:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "igd-next"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "0.14.3"
|
2023-10-19 04:27:21 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "064d90fec10d541084e7b39ead8875a5a80d9114a2b18791565253bae25f49e4"
|
2023-10-19 04:27:21 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"attohttpc",
|
|
|
|
"bytes",
|
|
|
|
"futures",
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2024-07-15 00:27:36 +00:00
|
|
|
"hyper 0.14.30",
|
2023-10-19 04:27:21 +00:00
|
|
|
"log",
|
|
|
|
"rand",
|
|
|
|
"tokio",
|
|
|
|
"url",
|
|
|
|
"xmltree",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "impl-codec"
|
|
|
|
version = "0.6.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ba6a270039626615617f3f36d15fc827041df3b78c439da2cadfa47455a77f2f"
|
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "impl-serde"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ebc88fc67028ae3db0c853baa36269d398d5f45b6982f95549ff5def78c935cd"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "impl-trait-for-tuples"
|
|
|
|
version = "0.2.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "11d7a9f6330b71fea57921c9b61c47ee6e84f72d394754eff6163ae67e7395eb"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-07-17 21:17:23 +00:00
|
|
|
[[package]]
|
2022-07-16 21:49:35 +00:00
|
|
|
name = "indexmap"
|
2023-03-25 04:45:33 +00:00
|
|
|
version = "1.9.3"
|
2022-07-17 21:17:23 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-25 04:45:33 +00:00
|
|
|
checksum = "bd070e393353796e801d209ad339e89596eb4c8d430d18ede6a1cced8fafbd99"
|
2022-07-17 21:17:23 +00:00
|
|
|
dependencies = [
|
2022-07-16 21:49:35 +00:00
|
|
|
"autocfg",
|
2023-03-06 12:39:43 +00:00
|
|
|
"hashbrown 0.12.3",
|
2023-10-23 10:59:38 +00:00
|
|
|
"serde",
|
2022-07-17 21:17:23 +00:00
|
|
|
]
|
|
|
|
|
2023-06-28 18:57:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "indexmap"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "2.5.0"
|
2023-06-28 18:57:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "68b900aa2f7301e21c36462b170ee99994de34dff39a4a6a528e80e7376d07e5"
|
2023-06-28 18:57:58 +00:00
|
|
|
dependencies = [
|
|
|
|
"equivalent",
|
2024-05-21 10:09:04 +00:00
|
|
|
"hashbrown 0.14.5",
|
2023-08-23 02:06:06 +00:00
|
|
|
"serde",
|
2023-06-28 18:57:58 +00:00
|
|
|
]
|
|
|
|
|
2022-10-29 08:54:42 +00:00
|
|
|
[[package]]
|
|
|
|
name = "inout"
|
|
|
|
version = "0.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a0c10553d664a4d0bcff9f4215d0aac67a639cc68ef660840afe309b807bc9f5"
|
|
|
|
dependencies = [
|
2023-10-31 11:41:23 +00:00
|
|
|
"block-padding",
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2022-10-29 08:54:42 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "instant"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.1.13"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "e0242819d153cba4b4b05a5a8f2a7e9bbf97b6055b2a002b395c96b5ff3c0222"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "integer-sqrt"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "276ec31bcb4a9ee45f58bec6f9ec700ae4cf4f4f8f2fa7e06cb406bd5ffdd770"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ip_network"
|
|
|
|
version = "0.4.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "aa2f047c0a98b2f299aa5d6d7088443570faae494e9ae1305e48be000c9e0eb1"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ipconfig"
|
2023-06-22 10:25:30 +00:00
|
|
|
version = "0.3.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-22 10:25:30 +00:00
|
|
|
checksum = "b58db92f96b720de98181bbbe63c831e87005ab460c1bf306eb2622b4707997f"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-05-21 10:09:04 +00:00
|
|
|
"socket2 0.5.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
"widestring",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2023-08-22 02:58:45 +00:00
|
|
|
"winreg",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ipnet"
|
2023-10-23 04:33:38 +00:00
|
|
|
version = "2.9.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-23 04:33:38 +00:00
|
|
|
checksum = "8f518f335dce6725a761382244631d86cf0ccb2863413590b31338feb467f9c3"
|
2022-12-07 22:56:53 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "is-terminal"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.4.10"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2024-05-21 12:07:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "is_terminal_polyfill"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.70.1"
|
2024-05-21 12:07:32 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "7943c866cc5cd64cbc25b2e01621d07fa8eb2a1a23160ee81ce38704e97b8ecf"
|
2024-05-21 12:07:32 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "itertools"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
version = "0.10.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b0fd2260e829bddf4cb6ea802289de2f86d6a7a690192fbe91b3f46e0f2c8473"
|
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "itertools"
|
|
|
|
version = "0.12.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
checksum = "ba291022dbbd398a455acf126c1e341954079855bc60dfdda641363bd6922569"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
]
|
|
|
|
|
2024-06-19 16:39:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "itertools"
|
|
|
|
version = "0.13.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "413ee7dfc52ee1a4949ceeb7dbc8a33f2d6c088194d9f922fb8318faf1f01186"
|
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "itoa"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "1.0.11"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "49f1f14873335454500d59611f1cf4a4b0f786f9ac11f4312a78e4cf2566695b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2024-05-21 12:07:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "jobserver"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.1.32"
|
2024-05-21 12:07:32 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "48d1dbcbbeb6a7fec7e059840aa538bd62aaccf972c7346c4d9d2059312853d0"
|
2024-05-21 12:07:32 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "js-sys"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.70"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "1868808506b929d7b0cfa8f75951347aa71bb21144b7791bae35d9bccfcfe37a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "jsonrpsee"
|
2023-08-23 17:18:51 +00:00
|
|
|
version = "0.16.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 17:18:51 +00:00
|
|
|
checksum = "367a292944c07385839818bb71c8d76611138e2dedb0677d035b8da21d29c78b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"jsonrpsee-core",
|
|
|
|
"jsonrpsee-proc-macros",
|
2023-01-04 08:17:36 +00:00
|
|
|
"jsonrpsee-server",
|
2022-07-16 21:49:35 +00:00
|
|
|
"jsonrpsee-types",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "jsonrpsee-core"
|
2023-08-23 17:18:51 +00:00
|
|
|
version = "0.16.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 17:18:51 +00:00
|
|
|
checksum = "2b5dde66c53d6dcdc8caea1874a45632ec0fcf5b437789f1e45766a1512ce803"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
2023-04-08 08:44:28 +00:00
|
|
|
"arrayvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"async-trait",
|
|
|
|
"beef",
|
|
|
|
"futures-channel",
|
|
|
|
"futures-util",
|
|
|
|
"globset",
|
2024-07-15 00:27:36 +00:00
|
|
|
"hyper 0.14.30",
|
2022-07-16 21:49:35 +00:00
|
|
|
"jsonrpsee-types",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rustc-hash",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2024-07-18 19:18:08 +00:00
|
|
|
"soketto 0.7.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "jsonrpsee-proc-macros"
|
2023-08-23 17:18:51 +00:00
|
|
|
version = "0.16.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 17:18:51 +00:00
|
|
|
checksum = "44e8ab85614a08792b9bff6c8feee23be78c98d0182d4c622c05256ab553892a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.4.1",
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-01-04 08:17:36 +00:00
|
|
|
name = "jsonrpsee-server"
|
2023-08-23 17:18:51 +00:00
|
|
|
version = "0.16.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 17:18:51 +00:00
|
|
|
checksum = "cf4d945a6008c9b03db3354fb3c83ee02d2faa9f2e755ec1dfb69c3551b8f4ba"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-channel",
|
|
|
|
"futures-util",
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2024-07-15 00:27:36 +00:00
|
|
|
"hyper 0.14.30",
|
2022-07-16 21:49:35 +00:00
|
|
|
"jsonrpsee-core",
|
|
|
|
"jsonrpsee-types",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2024-07-18 19:18:08 +00:00
|
|
|
"soketto 0.7.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tokio",
|
|
|
|
"tokio-stream",
|
|
|
|
"tokio-util",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tower",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-01-04 08:17:36 +00:00
|
|
|
name = "jsonrpsee-types"
|
2023-08-23 17:18:51 +00:00
|
|
|
version = "0.16.3"
|
2023-01-04 08:17:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 17:18:51 +00:00
|
|
|
checksum = "245ba8e5aa633dd1c1e4fae72bce06e71f42d34c14a2767c6b4d173b57bee5e5"
|
2023-01-04 08:17:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"beef",
|
|
|
|
"serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde_json",
|
2023-01-04 08:17:36 +00:00
|
|
|
"thiserror",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "k256"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "0.13.3"
|
2023-04-11 13:23:54 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "956ff9b67e26e1a6a866cb758f12c6f8746208489e3e4a4b5580802f2f0a587b"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-07-28 03:38:04 +00:00
|
|
|
"ecdsa",
|
|
|
|
"elliptic-curve",
|
2023-03-06 13:22:04 +00:00
|
|
|
"once_cell",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2024-05-21 04:29:33 +00:00
|
|
|
"signature",
|
2023-03-06 13:22:04 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "keccak"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "0.1.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "ecc2af9a1119c51f12a14607e783cb977bde58bc069ff0c3da1095e635d70654"
|
2022-11-21 07:23:38 +00:00
|
|
|
dependencies = [
|
|
|
|
"cpufeatures",
|
|
|
|
]
|
2022-07-16 21:49:35 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "keccak-asm"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.3"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "422fbc7ff2f2f5bdffeb07718e5a5324dca72b0c9293d50df4026652385e3314"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"digest 0.10.7",
|
|
|
|
"sha3-asm",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "kvdb"
|
2023-01-04 08:17:36 +00:00
|
|
|
version = "0.13.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-01-04 08:17:36 +00:00
|
|
|
checksum = "e7d770dcb02bf6835887c3a979b5107a04ff4bbde97a5f0928d27404a155add9"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "kvdb-memorydb"
|
2023-01-04 08:17:36 +00:00
|
|
|
version = "0.13.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-01-04 08:17:36 +00:00
|
|
|
checksum = "bf7a85fe66f9ff9cd74e169fdd2c94c6e1e74c412c99a73b4df3200b5d3760b2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"kvdb",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "kvdb-rocksdb"
|
2023-06-28 18:57:58 +00:00
|
|
|
version = "0.19.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-28 18:57:58 +00:00
|
|
|
checksum = "b644c70b92285f66bfc2032922a79000ea30af7bc2ab31902992a5dcb9b434f6"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"kvdb",
|
|
|
|
"num_cpus",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"regex",
|
2024-03-09 06:58:58 +00:00
|
|
|
"rocksdb 0.21.0",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "lazy_static"
|
2023-10-16 05:39:15 +00:00
|
|
|
version = "1.5.0"
|
|
|
|
source = "git+https://github.com/rust-lang-nursery/lazy-static.rs?rev=5735630d46572f1e5377c8f2ba0f79d18f53b10c#5735630d46572f1e5377c8f2ba0f79d18f53b10c"
|
2023-03-28 08:38:01 +00:00
|
|
|
dependencies = [
|
2023-10-16 05:39:15 +00:00
|
|
|
"spin 0.9.8",
|
2023-03-28 08:38:01 +00:00
|
|
|
]
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "lazycell"
|
|
|
|
version = "1.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "830d08ce1d1d941e6b30645f1a0eb5643013d835ce3779a5fc208261dbe10f55"
|
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "leb128"
|
|
|
|
version = "0.2.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "884e2677b40cc8c339eaefcb701c32ef1fd2493d71118dc0ca4b6a736c93bd67"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libc"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.158"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "d8adc4bb1803a324070e64a98ae98f38934d91957a99cfb3a43dcbc01bc56439"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libloading"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.8.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "4979f22fdb869068da03c9f7528f8297c6fd2606bc3a4affe42e6a823fdb8da4"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2024-09-06 03:31:45 +00:00
|
|
|
"windows-targets 0.52.6",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libm"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.2.8"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "4ec2a862134d2a7d32d7983ddcdd1c4923530833c9f2ea1a44fc5fa473989058"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p"
|
2023-10-19 04:27:21 +00:00
|
|
|
version = "0.52.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 04:27:21 +00:00
|
|
|
checksum = "e94495eb319a85b70a68b85e2389a95bb3555c71c49025b78c691a854a7e6464"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
2023-10-19 04:27:21 +00:00
|
|
|
"either",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
2023-10-16 19:07:39 +00:00
|
|
|
"getrandom",
|
2022-07-16 21:49:35 +00:00
|
|
|
"instant",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-allow-block-list",
|
|
|
|
"libp2p-connection-limits",
|
|
|
|
"libp2p-core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-dns",
|
2023-08-08 19:12:47 +00:00
|
|
|
"libp2p-gossipsub",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-identify",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-kad",
|
|
|
|
"libp2p-mdns",
|
|
|
|
"libp2p-metrics",
|
|
|
|
"libp2p-noise",
|
|
|
|
"libp2p-ping",
|
2023-08-25 03:55:47 +00:00
|
|
|
"libp2p-quic",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-request-response",
|
|
|
|
"libp2p-swarm",
|
|
|
|
"libp2p-tcp",
|
2023-10-19 04:27:21 +00:00
|
|
|
"libp2p-upnp",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-wasm-ext",
|
|
|
|
"libp2p-websocket",
|
|
|
|
"libp2p-yamux",
|
2023-06-28 18:57:58 +00:00
|
|
|
"multiaddr",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pin-project",
|
2023-10-19 04:27:21 +00:00
|
|
|
"rw-stream-sink",
|
|
|
|
"thiserror",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-06-28 18:57:58 +00:00
|
|
|
name = "libp2p-allow-block-list"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.2.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "55b46558c5c0bf99d3e2a1a38fd54ff5476ca66dd1737b12466a1824dd219311"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
|
|
|
"libp2p-swarm",
|
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-connection-limits"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.2.1"
|
2023-06-28 18:57:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "2f5107ad45cb20b2f6c3628c7b6014b996fcb13a88053f4569c872c6e30abf58"
|
2023-06-28 18:57:58 +00:00
|
|
|
dependencies = [
|
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
|
|
|
"libp2p-swarm",
|
2023-03-06 12:39:43 +00:00
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-core"
|
2023-09-24 12:31:13 +00:00
|
|
|
version = "0.40.1"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-24 12:31:13 +00:00
|
|
|
checksum = "dd44289ab25e4c9230d9246c475a22241e301b23e8f4061d3bdef304a1a99713"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"instant",
|
2023-03-16 23:37:32 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-06-28 18:57:58 +00:00
|
|
|
"multiaddr",
|
2023-09-12 11:47:03 +00:00
|
|
|
"multihash 0.19.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"multistream-select",
|
2023-01-16 15:42:31 +00:00
|
|
|
"once_cell",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pin-project",
|
2023-03-16 23:37:32 +00:00
|
|
|
"quick-protobuf",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rw-stream-sink",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"unsigned-varint",
|
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-dns"
|
2023-10-19 04:27:21 +00:00
|
|
|
version = "0.40.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 04:27:21 +00:00
|
|
|
checksum = "e6a18db73084b4da2871438f6239fef35190b05023de7656e877c18a00541a3b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-10-19 04:27:21 +00:00
|
|
|
"async-trait",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
2023-07-28 03:38:04 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"trust-dns-resolver",
|
|
|
|
]
|
|
|
|
|
2023-08-08 19:12:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-gossipsub"
|
2023-10-19 04:27:21 +00:00
|
|
|
version = "0.45.2"
|
2023-08-08 19:12:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 04:27:21 +00:00
|
|
|
checksum = "f1f9624e2a843b655f1c1b8262b8d5de6f309413fca4d66f01bb0662429f84dc"
|
2023-08-08 19:12:47 +00:00
|
|
|
dependencies = [
|
|
|
|
"asynchronous-codec",
|
2024-01-17 00:32:30 +00:00
|
|
|
"base64 0.21.7",
|
2023-08-08 19:12:47 +00:00
|
|
|
"byteorder",
|
|
|
|
"bytes",
|
|
|
|
"either",
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"futures-ticker",
|
2023-10-16 19:07:39 +00:00
|
|
|
"getrandom",
|
2023-08-08 19:12:47 +00:00
|
|
|
"hex_fmt",
|
|
|
|
"instant",
|
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
|
|
|
"libp2p-swarm",
|
|
|
|
"log",
|
|
|
|
"prometheus-client",
|
|
|
|
"quick-protobuf",
|
|
|
|
"quick-protobuf-codec",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-08-08 19:12:47 +00:00
|
|
|
"regex",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2023-08-08 19:12:47 +00:00
|
|
|
"unsigned-varint",
|
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-identify"
|
2023-10-19 04:27:21 +00:00
|
|
|
version = "0.43.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 04:27:21 +00:00
|
|
|
checksum = "45a96638a0a176bec0a4bcaebc1afa8cf909b114477209d7456ade52c61cd9cd"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"asynchronous-codec",
|
2023-06-28 18:57:58 +00:00
|
|
|
"either",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
2023-10-19 04:27:21 +00:00
|
|
|
"futures-bounded",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures-timer",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-swarm",
|
|
|
|
"log",
|
2023-07-19 02:30:55 +00:00
|
|
|
"lru",
|
2023-06-28 18:57:58 +00:00
|
|
|
"quick-protobuf",
|
|
|
|
"quick-protobuf-codec",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
2023-03-16 23:37:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-identity"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.2.9"
|
2023-03-16 23:37:32 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "55cca1eb2bc1fd29f099f3daaab7effd01e1a54b7c577d0ed082521034d912e8"
|
2023-03-16 23:37:32 +00:00
|
|
|
dependencies = [
|
2023-08-23 17:24:21 +00:00
|
|
|
"bs58",
|
2023-03-16 23:37:32 +00:00
|
|
|
"ed25519-dalek",
|
2023-10-16 19:07:39 +00:00
|
|
|
"hkdf",
|
2023-09-12 11:47:03 +00:00
|
|
|
"multihash 0.19.1",
|
2023-03-16 23:37:32 +00:00
|
|
|
"quick-protobuf",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-03-16 23:37:32 +00:00
|
|
|
"thiserror",
|
2023-11-15 22:18:24 +00:00
|
|
|
"tracing",
|
2023-03-16 23:37:32 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-kad"
|
2023-10-19 04:27:21 +00:00
|
|
|
version = "0.44.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 04:27:21 +00:00
|
|
|
checksum = "16ea178dabba6dde6ffc260a8e0452ccdc8f79becf544946692fff9d412fc29d"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-04-08 08:44:28 +00:00
|
|
|
"arrayvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"asynchronous-codec",
|
|
|
|
"bytes",
|
|
|
|
"either",
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"instant",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-swarm",
|
|
|
|
"log",
|
2023-06-28 18:57:58 +00:00
|
|
|
"quick-protobuf",
|
2023-09-24 12:31:13 +00:00
|
|
|
"quick-protobuf-codec",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"uint",
|
|
|
|
"unsigned-varint",
|
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-mdns"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.44.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "42a2567c305232f5ef54185e9604579a894fd0674819402bb0ac0246da82f52a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"data-encoding",
|
|
|
|
"futures",
|
|
|
|
"if-watch",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-swarm",
|
|
|
|
"log",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2024-05-21 10:09:04 +00:00
|
|
|
"socket2 0.5.7",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tokio",
|
2023-10-19 04:27:21 +00:00
|
|
|
"trust-dns-proto 0.22.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-metrics"
|
2023-08-15 09:39:23 +00:00
|
|
|
version = "0.13.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-15 09:39:23 +00:00
|
|
|
checksum = "239ba7d28f8d0b5d77760dc6619c05c7e88e74ec8fbbe97f856f20a56745e620"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"instant",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
2023-08-08 19:12:47 +00:00
|
|
|
"libp2p-gossipsub",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-identify",
|
2023-07-28 03:38:04 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-kad",
|
|
|
|
"libp2p-ping",
|
|
|
|
"libp2p-swarm",
|
2023-07-28 03:38:04 +00:00
|
|
|
"once_cell",
|
2022-07-16 21:49:35 +00:00
|
|
|
"prometheus-client",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-noise"
|
2023-10-16 19:07:39 +00:00
|
|
|
version = "0.43.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 19:07:39 +00:00
|
|
|
checksum = "d2eeec39ad3ad0677551907dd304b2f13f17208ccebe333bef194076cd2e8921"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-07-28 03:38:04 +00:00
|
|
|
"multiaddr",
|
2023-09-12 11:47:03 +00:00
|
|
|
"multihash 0.19.1",
|
2023-01-16 15:42:31 +00:00
|
|
|
"once_cell",
|
2023-06-28 18:57:58 +00:00
|
|
|
"quick-protobuf",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"snow",
|
|
|
|
"static_assertions",
|
2023-01-16 15:42:31 +00:00
|
|
|
"thiserror",
|
2023-07-28 03:38:04 +00:00
|
|
|
"x25519-dalek",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-ping"
|
2023-09-24 12:31:13 +00:00
|
|
|
version = "0.43.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-24 12:31:13 +00:00
|
|
|
checksum = "e702d75cd0827dfa15f8fd92d15b9932abe38d10d21f47c50438c71dd1b5dae3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"either",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"instant",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
2023-07-28 03:38:04 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-swarm",
|
|
|
|
"log",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-quic"
|
2023-10-19 04:27:21 +00:00
|
|
|
version = "0.9.3"
|
2023-08-25 03:55:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 04:27:21 +00:00
|
|
|
checksum = "130d451d83f21b81eb7b35b360bc7972aeafb15177784adc56528db082e6b927"
|
2023-08-25 03:55:47 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"if-watch",
|
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
|
|
|
"libp2p-tls",
|
|
|
|
"log",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-08-25 03:55:47 +00:00
|
|
|
"quinn",
|
|
|
|
"rand",
|
2023-11-06 12:19:55 +00:00
|
|
|
"ring 0.16.20",
|
2024-05-21 10:09:04 +00:00
|
|
|
"rustls 0.21.12",
|
|
|
|
"socket2 0.5.7",
|
2023-08-25 03:55:47 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-request-response"
|
2023-10-28 03:14:54 +00:00
|
|
|
version = "0.25.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-28 03:14:54 +00:00
|
|
|
checksum = "d8e3b4d67870478db72bac87bfc260ee6641d0734e0e3e275798f089c3fecfd4"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"futures",
|
|
|
|
"instant",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p-swarm",
|
2023-07-28 03:38:04 +00:00
|
|
|
"log",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2023-07-28 03:38:04 +00:00
|
|
|
"void",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-swarm"
|
2023-10-28 03:14:54 +00:00
|
|
|
version = "0.43.7"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-28 03:14:54 +00:00
|
|
|
checksum = "580189e0074af847df90e75ef54f3f30059aedda37ea5a1659e8b9fca05c0141"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"instant",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
2023-01-16 15:42:31 +00:00
|
|
|
"libp2p-swarm-derive",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-07-28 03:38:04 +00:00
|
|
|
"multistream-select",
|
|
|
|
"once_cell",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2023-01-16 15:42:31 +00:00
|
|
|
"tokio",
|
2022-07-16 21:49:35 +00:00
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-swarm-derive"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.33.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "c4d5ec2a3df00c7836d7696c136274c9c59705bac69133253696a6c932cd1d74"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.4.1",
|
2023-07-28 03:38:04 +00:00
|
|
|
"proc-macro-warning",
|
|
|
|
"proc-macro2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-tcp"
|
2023-10-19 04:27:21 +00:00
|
|
|
version = "0.40.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 04:27:21 +00:00
|
|
|
checksum = "b558dd40d1bcd1aaaed9de898e9ec6a436019ecc2420dd0016e712fbb61c5508"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"if-watch",
|
|
|
|
"libc",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
2023-07-28 03:38:04 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2024-05-21 10:09:04 +00:00
|
|
|
"socket2 0.5.7",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tokio",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-tls"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8218d1d5482b122ccae396bbf38abdcb283ecc96fa54760e1dfd251f0546ac61"
|
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"futures-rustls",
|
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-identity",
|
|
|
|
"rcgen",
|
2023-11-06 12:19:55 +00:00
|
|
|
"ring 0.16.20",
|
2024-05-21 10:09:04 +00:00
|
|
|
"rustls 0.21.12",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-webpki 0.101.7",
|
2023-08-25 03:55:47 +00:00
|
|
|
"thiserror",
|
|
|
|
"x509-parser",
|
|
|
|
"yasna",
|
|
|
|
]
|
|
|
|
|
2023-10-19 04:27:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-upnp"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "82775a47b34f10f787ad3e2a22e2c1541e6ebef4fe9f28f3ac553921554c94c1"
|
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"igd-next",
|
|
|
|
"libp2p-core",
|
|
|
|
"libp2p-swarm",
|
|
|
|
"log",
|
|
|
|
"tokio",
|
|
|
|
"void",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libp2p-wasm-ext"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.40.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "1e5d8e3a9e07da0ef5b55a9f26c009c8fb3c725d492d8bb4b431715786eea79c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"js-sys",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"send_wrapper",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasm-bindgen",
|
|
|
|
"wasm-bindgen-futures",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-websocket"
|
2024-07-18 19:18:08 +00:00
|
|
|
version = "0.42.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-18 19:18:08 +00:00
|
|
|
checksum = "004ee9c4a4631435169aee6aad2f62e3984dc031c43b6d29731e8e82a016c538"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
"futures",
|
|
|
|
"futures-rustls",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
2023-07-28 03:38:04 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rw-stream-sink",
|
2024-07-18 19:18:08 +00:00
|
|
|
"soketto 0.8.0",
|
|
|
|
"thiserror",
|
2022-07-16 21:49:35 +00:00
|
|
|
"url",
|
2023-10-28 03:14:54 +00:00
|
|
|
"webpki-roots",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libp2p-yamux"
|
2023-08-15 09:39:23 +00:00
|
|
|
version = "0.44.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-15 09:39:23 +00:00
|
|
|
checksum = "8eedcb62824c4300efb9cfd4e2a6edaf3ca097b9e68b36dabe45a44469fd6a85"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-core",
|
2022-10-20 05:05:36 +00:00
|
|
|
"log",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"yamux",
|
|
|
|
]
|
|
|
|
|
2024-05-21 12:07:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "libredox"
|
|
|
|
version = "0.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "c0ff37bd590ca25063e35af745c343cb7a0271906fb7b37e4813e8f79f00268d"
|
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
2024-05-21 12:07:32 +00:00
|
|
|
"libc",
|
2024-09-05 21:03:23 +00:00
|
|
|
"redox_syscall",
|
2024-05-21 12:07:32 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "librocksdb-sys"
|
2024-03-09 06:58:58 +00:00
|
|
|
version = "0.16.0+8.10.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-09 06:58:58 +00:00
|
|
|
checksum = "ce3d60bc059831dc1c83903fb45c103f75db65c5a7bf22272764d9cc683e348c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bindgen",
|
|
|
|
"bzip2-sys",
|
|
|
|
"cc",
|
|
|
|
"glob",
|
|
|
|
"libc",
|
|
|
|
"libz-sys",
|
2023-07-26 18:05:10 +00:00
|
|
|
"lz4-sys",
|
2024-03-09 06:58:58 +00:00
|
|
|
"zstd-sys",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "libz-sys"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.1.20"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "d2d16453e800a8cf6dd2fc3eb4bc99b786a9b90c663b8559a5b1a041bf89e472"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"pkg-config",
|
|
|
|
"vcpkg",
|
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "link-cplusplus"
|
2023-07-04 17:20:59 +00:00
|
|
|
version = "1.0.9"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-04 17:20:59 +00:00
|
|
|
checksum = "9d240c6f7e1ba3a28b0249f774e6a9dd0175054b52dfbb61b16eb8505c3785c9"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "linked-hash-map"
|
|
|
|
version = "0.5.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0717cef1bc8b636c6e1c1bbdefc09e6322da8a9321966e8928ef80d20f7f770f"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "linked_hash_set"
|
|
|
|
version = "0.1.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "47186c6da4d81ca383c7c47c1bfc80f4b95f4720514d860a5407aaf4233f9588"
|
|
|
|
dependencies = [
|
|
|
|
"linked-hash-map",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "linregress"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.5.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "4de04dcecc58d366391f9920245b85ffa684558a5ef6e7736e754347c3aea9c2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"nalgebra",
|
|
|
|
]
|
|
|
|
|
2023-07-02 00:27:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "linux-raw-sys"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.4.14"
|
2023-07-02 00:27:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "78b3ae25bc7c8c38cec158d1f2757ee79e9b3740fbc7ccf0e59e4b08d793fa89"
|
2023-07-02 00:27:03 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "lock_api"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.4.12"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "07af8b9cdd281b7915f413fa73f29ebd5d55d0d3f0155584dade1ff18cea1b17"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"autocfg",
|
|
|
|
"scopeguard",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "log"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.4.22"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "a7a70ba024b9dc04c27ea2f0c0548feb474ec5c54bba33a7f72f873a39d07b24"
|
2022-10-20 05:05:36 +00:00
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "loom"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.7.2"
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "419e0dc8046cb947daa77eb95ae174acfbddb7673b4151f56d1eed8e93fbfaca"
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"generator",
|
|
|
|
"scoped-tls",
|
|
|
|
"tracing",
|
|
|
|
"tracing-subscriber 0.3.17",
|
|
|
|
]
|
|
|
|
|
2023-04-09 06:31:10 +00:00
|
|
|
[[package]]
|
|
|
|
name = "lru"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.12.4"
|
2023-04-09 06:31:10 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "37ee39891760e7d94734f6f63fedc29a2e4a152f836120753a72503f09fcf904"
|
2023-04-09 06:31:10 +00:00
|
|
|
dependencies = [
|
2024-05-21 10:09:04 +00:00
|
|
|
"hashbrown 0.14.5",
|
2023-04-09 06:31:10 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "lru-cache"
|
|
|
|
version = "0.1.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "31e24f1ad8321ca0e8a1e0ac13f23cb668e6f5466c2c57319f6a5cf1cc8e3b1c"
|
|
|
|
dependencies = [
|
|
|
|
"linked-hash-map",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "lz4"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.26.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "958b4caa893816eea05507c20cfe47574a43d9a697138a7872990bba8a0ece68"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"lz4-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "lz4-sys"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.10.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "109de74d5d2353660401699a4174a4ff23fcc649caf553df71933c7fb45ad868"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mach"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-08 20:32:13 +00:00
|
|
|
checksum = "b823e83b2affd8f40a9ee8c29dbc56404c1e34cd2710921f2801e2cf29527afa"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2023-07-19 02:30:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "macro_magic"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.4.2"
|
2023-07-19 02:30:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "aee866bfee30d2d7e83835a4574aad5b45adba4cc807f2a3bbba974e5d4383c9"
|
2023-07-19 02:30:55 +00:00
|
|
|
dependencies = [
|
|
|
|
"macro_magic_core",
|
|
|
|
"macro_magic_macros",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-07-19 02:30:55 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "macro_magic_core"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.4.2"
|
2023-07-19 02:30:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "7e766a20fd9c72bab3e1e64ed63f36bd08410e75803813df210d1ce297d7ad00"
|
2023-07-19 02:30:55 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"const-random",
|
2023-07-19 02:30:55 +00:00
|
|
|
"derive-syn-parse",
|
|
|
|
"macro_magic_core_macros",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-07-19 02:30:55 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "macro_magic_core_macros"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.4.3"
|
2023-07-19 02:30:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "d710e1214dffbab3b5dacb21475dde7d6ed84c69ff722b3a47a782668d44fbac"
|
2023-07-19 02:30:55 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-07-19 02:30:55 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "macro_magic_macros"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.4.2"
|
2023-07-19 02:30:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "b8fb85ec1620619edf2984a7693497d4ec88a9665d8b87e942856884c92dbf2a"
|
2023-07-19 02:30:55 +00:00
|
|
|
dependencies = [
|
|
|
|
"macro_magic_core",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-07-19 02:30:55 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "match_cfg"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ffbee8634e0d45d258acb448e7eaab3fce7a0a467395d4d9f228e3c1f01fb2e4"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "matchers"
|
|
|
|
version = "0.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f099785f7595cc4b4553a174ce30dd7589ef93391ff414dbb67f62392b9e0ce1"
|
|
|
|
dependencies = [
|
2023-07-19 02:30:55 +00:00
|
|
|
"regex-automata 0.1.10",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "matchers"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8263075bb86c5a1b1427b5ae862e8889656f126e9f77c484496e8b47cf5c5558"
|
|
|
|
dependencies = [
|
|
|
|
"regex-automata 0.1.10",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "matches"
|
2023-01-28 06:47:13 +00:00
|
|
|
version = "0.1.10"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "matrixmultiply"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.3.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "9380b911e3e96d10c1f415da0876389aaf1b56759054eeb0de7df940c456ba1a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-05-01 07:17:37 +00:00
|
|
|
"autocfg",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rawpointer",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "md-5"
|
2023-09-24 12:31:13 +00:00
|
|
|
version = "0.10.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-24 12:31:13 +00:00
|
|
|
checksum = "d89e7ee0cfbedfc4da3340218492196241d89eefb6dab27de5df917a6d2e78cf"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-09-24 12:31:13 +00:00
|
|
|
"cfg-if",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "memchr"
|
2024-06-19 16:39:47 +00:00
|
|
|
version = "2.7.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-19 16:39:47 +00:00
|
|
|
checksum = "78ca9ab1a0babb1e7d5695e3530886289c18cf2f87ec19a575a0abdce112e3a3"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "memfd"
|
2023-09-20 08:30:46 +00:00
|
|
|
version = "0.6.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-20 08:30:46 +00:00
|
|
|
checksum = "b2cffa4ad52c6f791f4f8b15f0c05f9824b2ced1160e88cc393d64fff9a8ac64"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "memmap2"
|
2023-03-06 12:39:43 +00:00
|
|
|
version = "0.5.10"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-06 12:39:43 +00:00
|
|
|
checksum = "83faa42c0a078c393f6b29d5db232d8be22776a891f8f56e5284faee4a20b327"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "memoffset"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "0.9.1"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "488016bfae457b036d996092f6cb448677611ce4449e970ceaf42695203f218a"
|
2023-03-06 12:39:43 +00:00
|
|
|
dependencies = [
|
|
|
|
"autocfg",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "memory-db"
|
2023-03-26 12:43:01 +00:00
|
|
|
version = "0.32.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-26 12:43:01 +00:00
|
|
|
checksum = "808b50db46293432a45e63bc15ea51e0ab4c0a1647b8eb114e31a3e698dd6fbe"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"hash-db",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "merlin"
|
|
|
|
version = "3.0.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "58c38e2799fc0978b65dfff8023ec7843e2330bb462f19198840b34b6582397d"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
"keccak",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "mini-serai"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"loom",
|
|
|
|
]
|
|
|
|
|
2022-08-29 07:32:59 +00:00
|
|
|
[[package]]
|
|
|
|
name = "minimal-ed448"
|
2023-08-08 22:18:59 +00:00
|
|
|
version = "0.4.0"
|
2022-08-29 07:32:59 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"crypto-bigint",
|
|
|
|
"ff",
|
2022-12-24 20:09:09 +00:00
|
|
|
"ff-group-tests",
|
2024-07-15 00:27:36 +00:00
|
|
|
"generic-array 1.1.0",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2022-08-29 07:32:59 +00:00
|
|
|
"hex",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-28 08:43:10 +00:00
|
|
|
"rustversion",
|
2022-08-29 07:32:59 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "minimal-lexical"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "68354c5c6bd36d73ff3feceb05efa59b6acb7626617f4962be322a825e61f79a"
|
|
|
|
|
2023-05-01 07:17:37 +00:00
|
|
|
[[package]]
|
|
|
|
name = "miniz_oxide"
|
2024-06-19 16:39:47 +00:00
|
|
|
version = "0.7.4"
|
2023-05-01 07:17:37 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-19 16:39:47 +00:00
|
|
|
checksum = "b8a240ddb74feaf34a79a7add65a741f3167852fba007066dcac1ca548d89c08"
|
2023-05-01 07:17:37 +00:00
|
|
|
dependencies = [
|
|
|
|
"adler",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "mio"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "80e04d1dcff3aae0704555fe5fee3bcfaf3d1fdf8a7e521d5b9d2b42acb52cec"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-08-01 08:06:09 +00:00
|
|
|
"hermit-abi",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libc",
|
2023-10-16 19:07:39 +00:00
|
|
|
"wasi",
|
2024-08-01 08:06:09 +00:00
|
|
|
"windows-sys 0.52.0",
|
2022-10-20 05:05:36 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mockall"
|
2023-03-26 12:43:01 +00:00
|
|
|
version = "0.11.4"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-26 12:43:01 +00:00
|
|
|
checksum = "4c84490118f2ee2d74570d114f3d0493cbf02790df303d2707606c3e14e07c96"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"downcast",
|
|
|
|
"fragile",
|
|
|
|
"lazy_static",
|
|
|
|
"mockall_derive",
|
|
|
|
"predicates",
|
|
|
|
"predicates-tree",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "mockall_derive"
|
2023-03-26 12:43:01 +00:00
|
|
|
version = "0.11.4"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-26 12:43:01 +00:00
|
|
|
checksum = "22ce75669015c4f47b289fd4d4f56e894e4c96003ffdf3ac51313126f94c6cbb"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "modular-frost"
|
2023-08-08 22:30:19 +00:00
|
|
|
version = "0.8.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-10-29 08:54:42 +00:00
|
|
|
"ciphersuite",
|
2022-07-16 21:49:35 +00:00
|
|
|
"dalek-ff-group",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-10-29 08:54:42 +00:00
|
|
|
"dkg",
|
2022-07-16 21:49:35 +00:00
|
|
|
"flexible-transcript",
|
|
|
|
"hex",
|
2022-08-29 07:32:59 +00:00
|
|
|
"minimal-ed448",
|
2022-07-16 21:49:35 +00:00
|
|
|
"multiexp",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand_chacha",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-10-29 08:54:42 +00:00
|
|
|
"schnorr-signatures",
|
2022-10-13 04:38:36 +00:00
|
|
|
"serde_json",
|
|
|
|
"subtle",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
Utilize zeroize (#76)
* Apply Zeroize to nonces used in Bulletproofs
Also makes bit decomposition constant time for a given amount of
outputs.
* Fix nonce reuse for single-signer CLSAG
* Attach Zeroize to most structures in Monero, and ZOnDrop to anything with private data
* Zeroize private keys and nonces
* Merge prepare_outputs and prepare_transactions
* Ensure CLSAG is constant time
* Pass by borrow where needed, bug fixes
The past few commitments have been one in-progress chunk which I've
broken up as best read.
* Add Zeroize to FROST structs
Still needs to zeroize internally, yet next step. Not quite as
aggressive as Monero, partially due to the limitations of HashMaps,
partially due to less concern about metadata, yet does still delete a
few smaller items of metadata (group key, context string...).
* Remove Zeroize from most Monero multisig structs
These structs largely didn't have private data, just fields with private
data, yet those fields implemented ZeroizeOnDrop making them already
covered. While there is still traces of the transaction left in RAM,
fully purging that was never the intent.
* Use Zeroize within dleq
bitvec doesn't offer Zeroize, so a manual zeroing has been implemented.
* Use Zeroize for random_nonce
It isn't perfect, due to the inability to zeroize the digest, and due to
kp256 requiring a few transformations. It does the best it can though.
Does move the per-curve random_nonce to a provided one, which is allowed
as of https://github.com/cfrg/draft-irtf-cfrg-frost/pull/231.
* Use Zeroize on FROST keygen/signing
* Zeroize constant time multiexp.
* Correct when FROST keygen zeroizes
* Move the FROST keys Arc into FrostKeys
Reduces amount of instances in memory.
* Manually implement Debug for FrostCore to not leak the secret share
* Misc bug fixes
* clippy + multiexp test bug fixes
* Correct FROST key gen share summation
It leaked our own share for ourself.
* Fix cross-group DLEq tests
2022-08-03 08:25:18 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
[[package]]
|
|
|
|
name = "monero-address"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"hex",
|
|
|
|
"hex-literal",
|
|
|
|
"monero-io",
|
|
|
|
"monero-primitives",
|
|
|
|
"rand_core",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"std-shims",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-borromean"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"monero-generators",
|
|
|
|
"monero-io",
|
|
|
|
"monero-primitives",
|
|
|
|
"std-shims",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-bulletproofs"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"hex-literal",
|
|
|
|
"monero-generators",
|
|
|
|
"monero-io",
|
|
|
|
"monero-primitives",
|
|
|
|
"rand_core",
|
|
|
|
"std-shims",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-clsag"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"dalek-ff-group",
|
|
|
|
"flexible-transcript",
|
|
|
|
"group",
|
|
|
|
"modular-frost",
|
|
|
|
"monero-generators",
|
|
|
|
"monero-io",
|
|
|
|
"monero-primitives",
|
|
|
|
"rand_chacha",
|
|
|
|
"rand_core",
|
|
|
|
"std-shims",
|
|
|
|
"subtle",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-08-21 10:36:53 +00:00
|
|
|
[[package]]
|
|
|
|
name = "monero-generators"
|
2023-08-08 22:18:59 +00:00
|
|
|
version = "0.4.0"
|
2022-08-21 10:36:53 +00:00
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2022-08-21 10:36:53 +00:00
|
|
|
"dalek-ff-group",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2024-02-18 04:16:16 +00:00
|
|
|
"hex",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"monero-io",
|
2022-10-20 05:05:36 +00:00
|
|
|
"sha3",
|
2023-04-22 08:38:47 +00:00
|
|
|
"std-shims",
|
2022-08-21 10:36:53 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
[[package]]
|
|
|
|
name = "monero-io"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"std-shims",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-mlsag"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"monero-generators",
|
|
|
|
"monero-io",
|
|
|
|
"monero-primitives",
|
|
|
|
"std-shims",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"hex",
|
|
|
|
"monero-generators",
|
|
|
|
"monero-io",
|
|
|
|
"sha3",
|
|
|
|
"std-shims",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-rpc"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"hex",
|
|
|
|
"monero-address",
|
|
|
|
"monero-serai",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"std-shims",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-seed"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"hex",
|
|
|
|
"monero-primitives",
|
|
|
|
"rand_core",
|
|
|
|
"std-shims",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "monero-serai"
|
2023-03-21 00:28:41 +00:00
|
|
|
version = "0.1.4-alpha"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"curve25519-dalek",
|
2023-04-13 11:57:35 +00:00
|
|
|
"hex",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"hex-literal",
|
|
|
|
"monero-borromean",
|
|
|
|
"monero-bulletproofs",
|
|
|
|
"monero-clsag",
|
|
|
|
"monero-generators",
|
|
|
|
"monero-io",
|
|
|
|
"monero-mlsag",
|
|
|
|
"monero-primitives",
|
2023-04-13 11:57:35 +00:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"std-shims",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-serai-verify-chain"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"hex",
|
|
|
|
"monero-rpc",
|
|
|
|
"monero-serai",
|
|
|
|
"monero-simple-request-rpc",
|
|
|
|
"rand_core",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-simple-request-rpc"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"digest_auth",
|
|
|
|
"hex",
|
|
|
|
"monero-address",
|
|
|
|
"monero-rpc",
|
|
|
|
"simple-request",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "monero-wallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2022-07-16 21:49:35 +00:00
|
|
|
"dalek-ff-group",
|
|
|
|
"flexible-transcript",
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2022-07-16 21:49:35 +00:00
|
|
|
"hex",
|
|
|
|
"modular-frost",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"monero-address",
|
2024-09-13 09:11:07 +00:00
|
|
|
"monero-clsag",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"monero-rpc",
|
|
|
|
"monero-serai",
|
|
|
|
"monero-simple-request-rpc",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
|
|
|
"rand_chacha",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rand_distr",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2023-06-29 01:16:33 +00:00
|
|
|
"std-shims",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
Utilize zeroize (#76)
* Apply Zeroize to nonces used in Bulletproofs
Also makes bit decomposition constant time for a given amount of
outputs.
* Fix nonce reuse for single-signer CLSAG
* Attach Zeroize to most structures in Monero, and ZOnDrop to anything with private data
* Zeroize private keys and nonces
* Merge prepare_outputs and prepare_transactions
* Ensure CLSAG is constant time
* Pass by borrow where needed, bug fixes
The past few commitments have been one in-progress chunk which I've
broken up as best read.
* Add Zeroize to FROST structs
Still needs to zeroize internally, yet next step. Not quite as
aggressive as Monero, partially due to the limitations of HashMaps,
partially due to less concern about metadata, yet does still delete a
few smaller items of metadata (group key, context string...).
* Remove Zeroize from most Monero multisig structs
These structs largely didn't have private data, just fields with private
data, yet those fields implemented ZeroizeOnDrop making them already
covered. While there is still traces of the transaction left in RAM,
fully purging that was never the intent.
* Use Zeroize within dleq
bitvec doesn't offer Zeroize, so a manual zeroing has been implemented.
* Use Zeroize for random_nonce
It isn't perfect, due to the inability to zeroize the digest, and due to
kp256 requiring a few transformations. It does the best it can though.
Does move the per-curve random_nonce to a provided one, which is allowed
as of https://github.com/cfrg/draft-irtf-cfrg-frost/pull/231.
* Use Zeroize on FROST keygen/signing
* Zeroize constant time multiexp.
* Correct when FROST keygen zeroizes
* Move the FROST keys Arc into FrostKeys
Reduces amount of instances in memory.
* Manually implement Debug for FrostCore to not leak the secret share
* Misc bug fixes
* clippy + multiexp test bug fixes
* Correct FROST key gen share summation
It leaked our own share for ourself.
* Fix cross-group DLEq tests
2022-08-03 08:25:18 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
[[package]]
|
|
|
|
name = "monero-wallet-util"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"curve25519-dalek",
|
|
|
|
"hex",
|
|
|
|
"monero-seed",
|
|
|
|
"monero-wallet",
|
|
|
|
"polyseed",
|
|
|
|
"rand_core",
|
|
|
|
"std-shims",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "multiaddr"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.18.1"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "8b852bc02a2da5feed68cd14fa50d0774b92790a5bdbfa932a813926c8472070"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"arrayref",
|
|
|
|
"byteorder",
|
|
|
|
"data-encoding",
|
2023-07-28 03:38:04 +00:00
|
|
|
"libp2p-identity",
|
2023-03-06 12:39:43 +00:00
|
|
|
"multibase",
|
2023-09-12 11:47:03 +00:00
|
|
|
"multihash 0.19.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"percent-encoding",
|
|
|
|
"serde",
|
|
|
|
"static_assertions",
|
|
|
|
"unsigned-varint",
|
|
|
|
"url",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multibase"
|
|
|
|
version = "0.9.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9b3539ec3c1f04ac9748a260728e855f261b4977f5c3406612c884564f329404"
|
|
|
|
dependencies = [
|
|
|
|
"base-x",
|
|
|
|
"data-encoding",
|
|
|
|
"data-encoding-macro",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multiexp"
|
2023-08-08 22:18:59 +00:00
|
|
|
version = "0.4.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"dalek-ff-group",
|
2023-07-28 03:38:04 +00:00
|
|
|
"ff",
|
|
|
|
"group",
|
2023-03-28 08:38:01 +00:00
|
|
|
"k256",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-28 08:43:10 +00:00
|
|
|
"rustversion",
|
2023-04-22 08:38:47 +00:00
|
|
|
"std-shims",
|
Utilize zeroize (#76)
* Apply Zeroize to nonces used in Bulletproofs
Also makes bit decomposition constant time for a given amount of
outputs.
* Fix nonce reuse for single-signer CLSAG
* Attach Zeroize to most structures in Monero, and ZOnDrop to anything with private data
* Zeroize private keys and nonces
* Merge prepare_outputs and prepare_transactions
* Ensure CLSAG is constant time
* Pass by borrow where needed, bug fixes
The past few commitments have been one in-progress chunk which I've
broken up as best read.
* Add Zeroize to FROST structs
Still needs to zeroize internally, yet next step. Not quite as
aggressive as Monero, partially due to the limitations of HashMaps,
partially due to less concern about metadata, yet does still delete a
few smaller items of metadata (group key, context string...).
* Remove Zeroize from most Monero multisig structs
These structs largely didn't have private data, just fields with private
data, yet those fields implemented ZeroizeOnDrop making them already
covered. While there is still traces of the transaction left in RAM,
fully purging that was never the intent.
* Use Zeroize within dleq
bitvec doesn't offer Zeroize, so a manual zeroing has been implemented.
* Use Zeroize for random_nonce
It isn't perfect, due to the inability to zeroize the digest, and due to
kp256 requiring a few transformations. It does the best it can though.
Does move the per-curve random_nonce to a provided one, which is allowed
as of https://github.com/cfrg/draft-irtf-cfrg-frost/pull/231.
* Use Zeroize on FROST keygen/signing
* Zeroize constant time multiexp.
* Correct when FROST keygen zeroizes
* Move the FROST keys Arc into FrostKeys
Reduces amount of instances in memory.
* Manually implement Debug for FrostCore to not leak the secret share
* Misc bug fixes
* clippy + multiexp test bug fixes
* Correct FROST key gen share summation
It leaked our own share for ourself.
* Fix cross-group DLEq tests
2022-08-03 08:25:18 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multihash"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.18.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "cfd8a792c1694c6da4f68db0a9d707c72bd260994da179e6030a5dcee00bb815"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"blake2b_simd",
|
|
|
|
"blake2s_simd",
|
|
|
|
"blake3",
|
2024-05-21 09:27:01 +00:00
|
|
|
"core2",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"multihash-derive 0.8.0",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-10-20 05:05:36 +00:00
|
|
|
"sha3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"unsigned-varint",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-07-28 03:38:04 +00:00
|
|
|
name = "multihash"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.19.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "076d548d76a0e2a0d4ab471d0b1c36c577786dfc4471242035d97a12a735c492"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-05-21 09:27:01 +00:00
|
|
|
"core2",
|
2023-07-28 03:38:04 +00:00
|
|
|
"unsigned-varint",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-07-28 03:38:04 +00:00
|
|
|
name = "multihash-codetable"
|
2023-11-06 12:19:55 +00:00
|
|
|
version = "0.1.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-06 12:19:55 +00:00
|
|
|
checksum = "f6d815ecb3c8238d00647f8630ede7060a642c9f704761cd6082cb4028af6935"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"blake2b_simd",
|
|
|
|
"blake2s_simd",
|
|
|
|
"blake3",
|
2024-05-21 09:27:01 +00:00
|
|
|
"core2",
|
2023-07-28 03:38:04 +00:00
|
|
|
"digest 0.10.7",
|
|
|
|
"multihash-derive 0.9.0",
|
|
|
|
"ripemd",
|
2023-11-06 12:19:55 +00:00
|
|
|
"sha1",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-07-28 03:38:04 +00:00
|
|
|
"sha3",
|
|
|
|
"strobe-rs",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multihash-derive"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fc076939022111618a5026d3be019fd8b366e76314538ff9a1b59ffbcbf98bcd"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2023-07-28 03:38:04 +00:00
|
|
|
"proc-macro-error",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
"synstructure",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multihash-derive"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "890e72cb7396cb99ed98c1246a97b243cc16394470d94e0bc8b0c2c11d84290e"
|
|
|
|
dependencies = [
|
2024-05-21 09:27:01 +00:00
|
|
|
"core2",
|
2023-09-12 11:47:03 +00:00
|
|
|
"multihash 0.19.1",
|
2023-07-28 03:38:04 +00:00
|
|
|
"multihash-derive-impl",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multihash-derive-impl"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d38685e08adb338659871ecfc6ee47ba9b22dcc8abcf6975d379cc49145c3040"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2023-07-28 03:38:04 +00:00
|
|
|
"proc-macro-error",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"syn 1.0.109",
|
|
|
|
"synstructure",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multimap"
|
|
|
|
version = "0.8.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e5ce46fe64a9d73be07dcbe690a38ce1b293be448fd8ce1e6c1b8062c9f72c6a"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "multistream-select"
|
|
|
|
version = "0.13.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ea0df8e5eec2298a62b326ee4f0d7fe1a6b90a09dfcf9df37b38f947a8c42f19"
|
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"pin-project",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"unsigned-varint",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nalgebra"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.32.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "7b5c17de023a86f59ed79891b2e5d5a94c705dbe904a5b5c9c952ea6221b03e4"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"approx",
|
|
|
|
"matrixmultiply",
|
|
|
|
"nalgebra-macros",
|
|
|
|
"num-complex",
|
2022-09-29 18:33:09 +00:00
|
|
|
"num-rational",
|
2022-07-16 21:49:35 +00:00
|
|
|
"num-traits",
|
|
|
|
"simba",
|
|
|
|
"typenum",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nalgebra-macros"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.2.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "254a5372af8fc138e36684761d3c0cdb758a4410e938babcff1c860ce14ddbfc"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "names"
|
2023-04-09 06:31:10 +00:00
|
|
|
version = "0.14.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-09 06:31:10 +00:00
|
|
|
checksum = "7bddcd3bf5144b6392de80e04c347cd7fab2508f6df16a85fc496ecd5cec39bc"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "netlink-packet-core"
|
|
|
|
version = "0.4.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "345b8ab5bd4e71a2986663e88c56856699d060e78e152e6e9d7966fcd5491297"
|
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"byteorder",
|
|
|
|
"libc",
|
|
|
|
"netlink-packet-utils",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "netlink-packet-route"
|
|
|
|
version = "0.12.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d9ea4302b9759a7a88242299225ea3688e63c85ea136371bb6cf94fd674efaab"
|
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
2023-06-28 18:57:58 +00:00
|
|
|
"bitflags 1.3.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"byteorder",
|
|
|
|
"libc",
|
|
|
|
"netlink-packet-core",
|
|
|
|
"netlink-packet-utils",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "netlink-packet-utils"
|
2023-03-06 12:39:43 +00:00
|
|
|
version = "0.5.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-06 12:39:43 +00:00
|
|
|
checksum = "0ede8a08c71ad5a95cdd0e4e52facd37190977039a4704eb82a283f713747d34"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"byteorder",
|
|
|
|
"paste",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "netlink-proto"
|
|
|
|
version = "0.10.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "65b4b14489ab424703c092062176d52ba55485a89c076b4f9db05092b7223aa6"
|
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures",
|
|
|
|
"log",
|
|
|
|
"netlink-packet-core",
|
|
|
|
"netlink-sys",
|
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "netlink-sys"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "0.8.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "416060d346fbaf1f23f9512963e3e878f1a78e707cb699ba9215761754244307"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures",
|
|
|
|
"libc",
|
|
|
|
"log",
|
2023-01-16 15:42:31 +00:00
|
|
|
"tokio",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nix"
|
2022-12-07 22:56:53 +00:00
|
|
|
version = "0.24.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-12-07 22:56:53 +00:00
|
|
|
checksum = "fa52e972a9a719cecb6864fb88568781eb706bac2cd1d4f04a648542dbf78069"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"bitflags 1.3.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cfg-if",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nohash-hasher"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2bf50223579dc7cdcfb3bfcacf7069ff68243f8c363f62ffa99cf000a6b9c451"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "nom"
|
2023-01-16 15:42:31 +00:00
|
|
|
version = "7.1.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-01-16 15:42:31 +00:00
|
|
|
checksum = "d273983c5a657a70a3e8f2a01329822f3b8c8172b73826411a55751e404a0a4a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
"minimal-lexical",
|
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "normalize-line-endings"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "61807f77802ff30975e01f4f071c8ba10c022052f98b3294119f3e615d13e5be"
|
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "nu-ansi-term"
|
|
|
|
version = "0.46.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "77a8165726e8236064dbb45459242600304b42a5ea24ee2948e18e023bf7ba84"
|
|
|
|
dependencies = [
|
|
|
|
"overload",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "num-bigint"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.4.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "a5e44f723f1133c9deac646763579fdb3ac745e418f2a7af9cd0c431da1f20b9"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-complex"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.4.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "73f88a1307638156682bada9d7604135552957b7818057dcef22705b4d509495"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
2024-05-21 12:07:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "num-conv"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "51d515d32fb182ee37cda2ccdcb92950d6a3c2893aa280e540671c2cd0f3b1d9"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "num-format"
|
2022-12-07 22:56:53 +00:00
|
|
|
version = "0.4.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-12-07 22:56:53 +00:00
|
|
|
checksum = "a652d9771a63711fd3c3deb670acfbe5c30a4072e664d7a3bf5a9e1056ac72c3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-04-08 08:44:28 +00:00
|
|
|
"arrayvec",
|
2022-10-20 05:05:36 +00:00
|
|
|
"itoa",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-integer"
|
2024-02-09 07:48:44 +00:00
|
|
|
version = "0.1.46"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-09 07:48:44 +00:00
|
|
|
checksum = "7969661fd2958a5cb096e56c8e1ad0444ac2bbcd0061bd28660485a44879858f"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-rational"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.4.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "f83d14da390562dca69fc84082e73e548e1ad308d24accdedd2720017cb37824"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"num-bigint",
|
2022-07-16 21:49:35 +00:00
|
|
|
"num-integer",
|
|
|
|
"num-traits",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num-traits"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.2.19"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "071dfc062690e90b734c0b2273ce72ad0ffa95f0c74596bc250dcfd960262841"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"autocfg",
|
2023-08-17 05:25:50 +00:00
|
|
|
"libm",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num_cpus"
|
2023-07-02 00:27:03 +00:00
|
|
|
version = "1.16.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-02 00:27:03 +00:00
|
|
|
checksum = "4161fcb6d602d4d2081af7c3a45852d875a03dd337a6bfdd6e06407b61342a43"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-02 00:27:03 +00:00
|
|
|
"hermit-abi",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2024-06-13 19:57:08 +00:00
|
|
|
[[package]]
|
|
|
|
name = "num_enum"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.7.3"
|
2024-06-13 19:57:08 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "4e613fc340b2220f734a8595782c551f1250e969d87d3be1ae0579e8d4065179"
|
2024-06-13 19:57:08 +00:00
|
|
|
dependencies = [
|
|
|
|
"num_enum_derive",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "num_enum_derive"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.7.3"
|
2024-06-13 19:57:08 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "af1844ef2428cc3e1cb900be36181049ef3d3193c63e43026cfe202983b27a56"
|
2024-06-13 19:57:08 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2024-06-13 19:57:08 +00:00
|
|
|
]
|
|
|
|
|
2022-12-21 04:12:26 +00:00
|
|
|
[[package]]
|
|
|
|
name = "object"
|
2023-08-23 02:06:06 +00:00
|
|
|
version = "0.31.1"
|
2022-12-21 04:12:26 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 02:06:06 +00:00
|
|
|
checksum = "8bda667d9f2b5051b8833f59f3bf748b28ef54f850f4fcb389a252aa383866d1"
|
2022-12-21 04:12:26 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"crc32fast",
|
|
|
|
"hashbrown 0.13.2",
|
|
|
|
"indexmap 1.9.3",
|
2022-12-21 04:12:26 +00:00
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
2023-07-02 00:27:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "object"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.36.4"
|
2023-07-02 00:27:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "084f1a5821ac4c651660a94a7153d27ac9d8a53736203f58b31945ded098070a"
|
2023-07-02 00:27:03 +00:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "oid-registry"
|
|
|
|
version = "0.6.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9bedf36ffb6ba96c2eb7144ef6270557b52e54b20c0a8e1eb2ff99a6c6959bff"
|
|
|
|
dependencies = [
|
|
|
|
"asn1-rs",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "once_cell"
|
2023-12-15 05:54:39 +00:00
|
|
|
version = "1.19.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-15 05:54:39 +00:00
|
|
|
checksum = "3fdb12b2476b595f9358c5161aa467c2438859caa136dec86c26fdd2efe17b92"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "opaque-debug"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "0.3.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "c08d65885ee38876c4f86fa503fb49d7b507c2b62552df7c70b2fce627e06381"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "openssl-probe"
|
|
|
|
version = "0.1.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ff011a302c396a5197692431fc1948019154afc178baf7d8e37367442a4601cf"
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "option-ext"
|
|
|
|
version = "0.2.0"
|
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "overload"
|
|
|
|
version = "0.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b15813163c1d831bf4a13c3610c05c0d03b39feb07f7e09fa234dac9b15aaf39"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "p256"
|
2023-04-16 03:21:18 +00:00
|
|
|
version = "0.13.2"
|
2023-04-11 13:23:54 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-16 03:21:18 +00:00
|
|
|
checksum = "c9863ad85fa8f4460f9c48cb909d38a0d689dba1f6f6988a5e3e0d31071bcd4b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"ecdsa",
|
|
|
|
"elliptic-curve",
|
2023-03-06 13:22:04 +00:00
|
|
|
"primeorder",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-03-28 08:38:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pairing"
|
|
|
|
version = "0.23.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "81fec4625e73cf41ef4bb6846cafa6d44736525f442ba45e407c4a000a13996f"
|
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"group",
|
2023-03-28 08:38:01 +00:00
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pallet-authorship"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-03-26 12:43:01 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pallet-babe"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-benchmarking",
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"log",
|
|
|
|
"pallet-authorship",
|
|
|
|
"pallet-session",
|
|
|
|
"pallet-timestamp",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-consensus-babe",
|
2023-05-01 07:17:37 +00:00
|
|
|
"sp-core",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-session",
|
|
|
|
"sp-staking",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-03-26 12:43:01 +00:00
|
|
|
]
|
|
|
|
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
[[package]]
|
2023-03-26 12:43:01 +00:00
|
|
|
name = "pallet-grandpa"
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
dependencies = [
|
2023-03-26 12:43:01 +00:00
|
|
|
"frame-benchmarking",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"log",
|
2023-03-26 12:43:01 +00:00
|
|
|
"pallet-authorship",
|
|
|
|
"pallet-session",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-consensus-grandpa",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-session",
|
|
|
|
"sp-staking",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-03-26 12:43:01 +00:00
|
|
|
name = "pallet-session"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
2023-03-26 12:43:01 +00:00
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"log",
|
|
|
|
"pallet-timestamp",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"sp-core",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-session",
|
|
|
|
"sp-staking",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-trie",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pallet-timestamp"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-benchmarking",
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-timestamp",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pallet-transaction-payment"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pallet-transaction-payment-rpc"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"jsonrpsee",
|
|
|
|
"pallet-transaction-payment-rpc-runtime-api",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-rpc",
|
|
|
|
"sp-runtime",
|
2022-11-11 04:59:20 +00:00
|
|
|
"sp-weights",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pallet-transaction-payment-rpc-runtime-api"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"pallet-transaction-payment",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sp-api",
|
|
|
|
"sp-runtime",
|
2022-11-11 04:59:20 +00:00
|
|
|
"sp-weights",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parity-db"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "0.4.13"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "592a28a24b09c9dc20ac8afaa6839abc417c720afe42c12e1e4a9d6aa2508d2e"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-11-11 04:59:20 +00:00
|
|
|
"blake2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"crc32fast",
|
|
|
|
"fs2",
|
|
|
|
"hex",
|
|
|
|
"libc",
|
|
|
|
"log",
|
|
|
|
"lz4",
|
2022-09-18 19:30:38 +00:00
|
|
|
"memmap2",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-03-06 12:39:43 +00:00
|
|
|
"siphasher",
|
2022-07-16 21:49:35 +00:00
|
|
|
"snap",
|
2024-01-17 00:32:30 +00:00
|
|
|
"winapi",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parity-scale-codec"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "3.6.12"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "306800abfa29c7f16596b5970a588435e3d5b3149683d00c12b699cc19f895ee"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-04-08 08:44:28 +00:00
|
|
|
"arrayvec",
|
2023-08-23 17:24:21 +00:00
|
|
|
"bitvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"byte-slice-cast",
|
2022-09-29 18:33:09 +00:00
|
|
|
"bytes",
|
2022-07-16 21:49:35 +00:00
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"parity-scale-codec-derive",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parity-scale-codec-derive"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "3.6.12"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "d830939c76d294956402033aee57a6da7b438f2294eb94864c37b0569053a42c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"proc-macro-crate 3.2.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parity-wasm"
|
2022-09-29 18:33:09 +00:00
|
|
|
version = "0.45.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-09-29 18:33:09 +00:00
|
|
|
checksum = "e1ad0aff30c1da14b1254fcb2af73e1fa9a28670e584a626f53a369d0e157304"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parking"
|
2023-10-19 01:45:49 +00:00
|
|
|
version = "2.2.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 01:45:49 +00:00
|
|
|
checksum = "bb813b8af86854136c6922af0598d719255ecb2179515e6e7730d468f05c9cae"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parking_lot"
|
|
|
|
version = "0.11.2"
|
|
|
|
dependencies = [
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parking_lot"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.12.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "f1bf18183cf54e8d6059647fc3063646a1801cf30896933ec2311622cc4b9a27"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"lock_api",
|
2024-05-21 12:07:32 +00:00
|
|
|
"parking_lot_core 0.9.10",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parking_lot_core"
|
2022-12-21 04:12:26 +00:00
|
|
|
version = "0.8.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-05-21 12:07:32 +00:00
|
|
|
"parking_lot_core 0.9.10",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "parking_lot_core"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.9.10"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "1e401f977ab385c9e4e3ab30627d6f26d00e2c73eef317493c4ec6d468726cf8"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"libc",
|
2024-09-05 21:03:23 +00:00
|
|
|
"redox_syscall",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows-targets 0.52.6",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-06-28 18:57:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "partial_sort"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7924d1d0ad836f665c9065e26d016c673ece3993f30d340068b16f282afc1156"
|
|
|
|
|
add polyseed support (#257)
* add polyseed support
* fix pr comments
* fix tests
* Embed the mempool into the Blockchain
* Plan scheduled payments whenever outputs are received
The scheduler prior waited for the next series of payments to be added.
* Replace Tendermint step with sync_block
Step moved a step forward after an externally synced/added block. This created
a race condition to add the block between the sync process and the Tendermint
machine. Now that the block routes through Tendermint, there is no such race
condition.
* Finish binding Tendermint into Tributary and define a Tributary master object
* Add correction the last commit missed
* Add DoS limits to tributary and require provided transactions be ordered
* Fix the scheduler from dropping UTXOs when there weren't any payments
* Documentation and cargo update
* Add a dedicated db crate with a basic DB trait
It's needed by the processor and tributary (coordinator).
* Add a DB to Tributary
Adds support for reloading most of the blockchain.
* Reloaded provided transactions from the disk
Also resolves a race condition by asserting provided transactions must be
unique, allowing them to be safely provided multiple times.
* must_use annotations on DbTxn
* Support reloading the mempool from disk
* Add a NewSet event to validator-sets
Updates to the latest serai-dex/substrate due to depending on
10ccaca0eb498a2316bbf627d419b29b1a75933a.
* Add basic getters to tributary
* cargo update
* Update to the latest subxt
Writes a custom unsigned extrinic creator due to subxt having an internal error
with the scale metadata. While the code in our scope increased, it's much more
ergonomic to our usage. We may end up rewriting most of subxt, eventually.
* Make unsigned private due to unsafe calling potential
* Start defining the coordinator
* Merge AckBlock with Burns
Offers greater efficiency while reducing concerns re: atomicity.
* Correct processor flow to have the coordinator decide signing set/re-attempts
The signing set should be the first group to submit preprocesses to Tributary.
Re-attempts shouldn't be once every 30s, yet n blocks since the last relevant
message.
Removes the use of an async task/channel in the signer (and Substrate signer).
Also removes the need to be able to get the time from a coin's block, which was
a fragile system marked with a TODO already.
* cargo +nightly fmt
* cargo update
Since p256 now pulls in an extra crate with this update, the {k,p}256 imports
disable default-features to prevent growing the tree.
* Support extracting timestamps from blocks
* Make progres on handling NewSet events
Further bones out the coordinator.
* Resolve #245
* Have InInstructions track the latest block for a network in storage
* Fill out code for the rest of the Substrate events
* Clean up the Substrate block processing code
* Rename transaction file to tributary, add function for genesis
* Add a processor API to the coordinator
* Add extensive commentary on mutable to the processor's main file
Clearly establishes why consistency is guaranteed from a Rust borrow-checker
mindset. While there are plenty of... 'violations', they're clearly explained.
Hopefully, this method of thinking helps promote/ensure consistency in the
future.
* Move ConfirmKeyPair from key_gen to substrate
Clarifies the emitter and accordingly why its mutations are justified.
* Remove BatchSigned
SubstrateBlock's provision of the most recently acknowledged block has
equivalent information with the same latency. Accordingly, there's no need for
it.
* Add note to processor_messages
* Use a single txn for an entire coordinator message
Removes direct DB accesses whre possible. Documents the safety of the rest.
Does uncover one case of unsafety not previously noted.
* cargo update to remove usage of yanked crate
* Clarify safety of Scanner::block_number and KeyGen::keys
* Tweak ConfirmKeyPair to alleviate database requirements of coordinator
* Use an enum for Coin/NetworkId
It originally wasn't an enum so software which had yet to update before an
integration wouldn't error (as now enums are strictly typed). The strict typing
is preferable though.
* Code a method to determine the activation block before any block has consensus
[0; 32] is a magic for no block has been set yet due to this being the first
key pair. If [0; 32] is the latest finalized block, the processor determines
an activation block based on timestamps.
This doesn't use an Option for ergonomic reasons.
* automate whitespace & trimming test cases
* Save keys by their tweaked group_key
Keys are referred to by their tweaked versions. If a tweak was needed, keys
would fail to confirm.
* Use crypto-bigint's reduction in ed448
Achieves feasible performance in the ed448 which makes it potentially viable
for real world usage.
Accordingly prepares a new release, updating the README.
* Move the entirety of ed448 to Residue, offering a further 2-4x speedup
* Resolve #68
Notably speeds up monero-serai's build and CLSAG performance.
* Make MainDB into SubstrateDB
* Initial Tributary handling
* Add additional checks to key_gen/sign
There is the ability to cause state bloat by flooding Tributary.
KeyGen/Sign specifically shouldn't allow bloat since we check the
commitments/preprocesses/shares for validity. Accordingly, any invalid data
(such as bloat) should be detected.
It was posssible to place bloat after the valid data. Doing so would be
considered a valid KeyGen/Sign message, yet could add up to 50k kB per sign.
* Apply DKG TX handling code to all sign TXs
The existing code was almost entirely applicable. It just needed to be scoped
with an ID. While the handle function is now a bit convoluted, I don't see a
better option.
* Split FinalizedBlock into ExternalBlock and SeraiBlock
Also re-arranges their orders.
* Add support for multiple orderings in Provided
Necessary as our Tributary chains needed to agree when a Serai block has
occurred, and when a Monero block has occurred. Since those could happen at the
same time, some validators may put SeraiBlock before ExternalBlock and vice
versa, causing a chain halt. Now they can have distinct ordering queues.
* Slash on unrecognized ID
* ExternalBlock handler
* Add a SubstrateBlockAck message to the processor
When a Substrate block occurs, the coordinator is expected to emit
SubstrateBlock. This causes the processor to begin a variety of plans. The
processor now emits SubstrateBlockAck, explicitly listing all plan IDs, before
starting signing.
This lets the coordinator provide a SubstrateBlock transaction, and with it,
recognize all plan IDs as valid.
Prior, we would've had to have a spotty algorithm based upon the upcoming
Preprocess messages, or if we immediately provided the SubstrateBlock
transaction, then wait for the processor to inform us of the contained plans.
This creates an explicitly proper async flow not reliant on waiting for data
availability.
Alternatively, we could've replaced Preprocess with (Block, Vec<Preprocess>).
This would've been more efficient, yet also clunky due to the multiple usages
of the Preprocess message.
* Route the SubstrateBlock message, which is the last Tributary transaction type
* Add recent bloat checks added to signer to substrate_signer as well
* Add no_std support to transcript, dalek-ff-group, ed448, ciphersuite, multiexp, schnorr, and monero-generators
transcript, dalek-ff-group, ed449, and ciphersuite are all usable with no_std
alone. The rest additionally require alloc.
Part of #279.
* Add a test to the coordinator for running a Tributary
Impls a LocalP2p for testing.
Moves rebroadcasting into Tendermint, since it's what knows if a message is
fully valid + original.
Removes TributarySpec::validators() HashMap, as its non-determinism caused
different instances to have different round robin schedules. It was already
prior moved to a Vec for this issue, so I'm unsure why this remnant existed.
Also renames the GH no-std workflow from the prior commit.
* Add a test for Tributary
Further fleshes out the Tributary testing code.
* Test handling of DKG commitments transactions
* Add Transaction::sign.
While I don't love the introduction of empty_signed, it's practically fine.
* Tributary test wait_for_tx_inclusion function
* Additionally test DKGShares
* Handle adding new Tributaries
Removes last_block as an argument from Tendermint. It now loads from the DB as
needed. While slightly less performant, it's easiest and should be fine.
* Reload Tributaries
add_active_tributary writes the spec to disk before it returns, so even if the
VecDeque it pushes to isn't popped, the tributary will still be loaded on boot.
* Start handling P2P messages
This defines the tart of a very complex series of locks I'm really unhappy
with. At the same time, there's not immediately a better solution. This also
should work without issue.
* Clarify Arc RwLocks and sleeps in coordinator
* Send a heartbeat message when a Tributary falls behind
* cargo fmt
* cargo update
* Move json word lists to rs
Allows building the seed code without serde_json.
* Break coordinator main into multiple functions
Also moves from std::sync::RwLock to tokio::sync::RwLock to prevent wasting
cycles on spinning.
* Remove reliance on a blockchain read lock from block/commit
* Implement Tributary syncing
Also adds a forwards-lookup to the Tributary blockchain.
* Don't return from sync_block until the Tendermint machine returns if it's valid or not
We had a race condition where'd we be informed of blocks 1 .. 3, and
immediately add 1 .. 3. Because we immediately tried to add 2 after 1, it'd
fail since the tip was still the genesis, yet 2 needs the tip to be 1.
Adding a channel, while ugly, was the simplest way to accomplish this.
Also has any added block be broadcasted. Else there's a race condition where a
node which syncs up to the most recent block does so, yet fails to add the next
block when it's committed to.
* Test handle_p2p and Tributary syncing
Includes bug fixes.
* Tweak tests workflow
* Add a TributaryReader which doesn't require a borrow to operate
Reduces lock contention.
Additionally changes block_key to include the genesis. While not technically
needed, the lack of genesis introduced a side effect where any Tributary on the
the database could return the block of any other Tributary. While that wasn't a
security issue, returning it suggested it was on-chain when it wasn't. This may
have been usable to create issues.
* Document panic in FROST
* Document a pair of panics requiring 256 GB of RAM/4 GB of a context
* Add a UID function to messages
When we receive messages, we're provided with a message ID we can use to
prevent handling an item multiple times. That doesn't prevent us from *sending*
an item multiple times though. Thanks to the UID system, we can now not send if
already present.
Alternatively, we can remove the ordered message ID for just the UID, allowing
duplicates to be sent without issue, and handled on the receiving end.
* Initial code to handle messages from processors
* Document the processor/tributary/coordinator/serai flow
* Have Coordinator MainDb take a mutable borrow
* Update to substrate polkadot-v0.9.42
* Correct error message in ff-group-tests
* Update to May's nightly
Doesn't use the PR due to the needed changes.
* Support arbitrary RPC providers in monero-serai
Sets a clean path for no-std premised RPCs (buffers to an external RPC impl)/
Tor-based RPCs/client-side load balancing/...
* Correct processor's handling of the new Monero RPC code
* Correct Serai Dockerfile
* Publish ExternablBlock/SubstrateBlock, delay *Preprocess until ID acknowledged
Adds a channel for the Tributary scanner to communicate when an ID has been
acknowledged.
* Rename uid to intent
* Use U448 for Ed448 instead of U512
* Spawn a new async task for each block message
This probably should be done with n-long lived tasks, one per Tributary. While
this may not be suitably performant long-term (potential DoS vector), this at
least resolves the halting concerns.
* Move the coordinator to a n-processor design
* Ensure Tributary commits are minimal
* Properly get genesis for a Processor message
* Create a vote transaction upon GeneratedKeyPair
* Remove TODO about code de-duplication
It's infeasible to write a macro/function there. Does add a type alias which
makes things cleaner.
* Have coordinator publish batches to Substrate
* Implement MuSig key aggregation into DKG
Isn't spec compliant due to the lack of a spec to be compliant too.
Slight deviation from the paper by using a unique list instead of a multiset.
Closes #186, progresses #277.
* Correct 2/3rds definitions throughout the codebase
The prior formula failed for some values, such as 20.
20 / 3 = 6, * 2 = 12, + 1 = 13. 13 is 65%, not >= 67.
* cargo update
Resolves a yanked crate and removes some duplicated dependencies.
* Add a dedicated function to get a MuSig key
* Do the minimal amount of work for dkg to compile under no-std
The Substrate runtime requires access to the MuSig key aggregation function.
\#279 related.
* Use a MuSig signature to publish validator set key pairs to Serai
The processor/coordinator flow still has to be rewritten.
* Correct various no_std definitions
* Add a context to MuSig key aggregation
* Use proper messages for ValidatorSets/InInstructions pallet
Provides a DST, and associated metadata as beneficial.
Also utilizes MuSig's context to session-bind. Since set_keys_messages also
binds to set, this is semi-redundant, yet that's appreciated.
* Remove signed Substrate TXs from Coordinator
* Only scan v2 Monero TXs
* Fix for prior commit
* Ensure canonical points in the cross-group DLEq proof
* Fix incorrect sig_hash generation
sig_hash was used as a challenge. challenges should be of the form H(R, A, m).
These sig hashes were solely H(A, m), allowing trivial forgeries.
* cargo update
Resolves an openssl advisory and nets ~-8 crates.
* Build no-std tests with RISC-V 32 IMAC
Turns out wasm still has std, making it suboptimal to use here.
* Pin setup-protoc to v2.0.0
* Update to substrate polkadot-v0.9.43
* fix tributary sync test
* Slight terminology correction in sync test
Also correct a mistake from merging the most recent polkadot version.
* Update nightly
* Replace lazy_static with OnceLock inside monero-serai
lazy_static, if no_std environments were used, effectively required always
using spin locks. This resolves the ergonomics of that while adopting Rust std
code.
no_std does still use a spin based solution. Theoretically, we could use
atomics, yet writing our own Mutex wasn't a priority.
* no-std support for monero-serai (#311)
* Move monero-serai from std to std-shims, where possible
* no-std fixes
* Make the HttpRpc its own feature, thiserror only on std
* Drop monero-rs's epee for a homegrown one
We only need it for a single function. While I tried jeffro's, it didn't work
out of the box, had three unimplemented!s, and is no where near viable for
no_std.
Fixes #182, though should be further tested.
* no-std monero-serai
* Allow base58-monero via git
* cargo fmt
* Represent RCT amounts with None, not 0.
Fixes #282.
Does allow any v1 TXs which exist, and v2 miner-TXs, to specify Some(0). As far
as I can tell, both were/are theoreitcally possible.
* Add a message queue
This is intended to be a reliable transport between the processors and
coordinator. Since it'll be intranet only, it's written as never fail.
Primarily needs testing and a proper ID.
* cargo update
Resolves https://github.com/serai-dex/serai/security/dependabot/29
* Correct deny.toml with inclusion of message-queue
* Update nightly
* std-shims: six `Read` for &[u8]
* Use serai- prefixes on Serai-specific packages
Fixes deny.toml, also runs a minor cargo update shrinking the tree.
* Update monero-tests workflow to new name for the processor
* Correct depends for processor-messages
* Disable Rust caching
We hit the cache limit after just one or two builds, making it infeasible.
* cargo update
Resolves a yanked crate
* Move location of serai-client in Cargo.toml
* Monero: support for legacy transactions (#308)
* add mlsag
* fix last commit
* fix miner v1 txs
* fix non-miner v1 txs
* add borromean + fix mlsag
* add block hash calculations
* fix for the jokester that added unreduced scalars
to the borromean signature of
2368d846e671bf79a1f84c6d3af9f0bfe296f043f50cf17ae5e485384a53707b
* Add Borromean range proof verifying functionality
* Add MLSAG verifying functionality
* fmt & clippy :)
* update MLSAG, ss2_elements will always be 2
* Add MgSig proving
* Tidy block.rs
* Tidy Borromean, fix bugs in last commit, replace todo! with unreachable!
* Mark legacy EcdhInfo amount decryption as experimental
* Correct comments
* Write a new impl of the merkle algorithm
This one tries to be understandable.
* Only pull in things only needed for experimental when experimental
* Stop caching the Monero block hash now in processor that we have Block::hash
* Corrections for recent processor commit
* Use a clearer algorithm for the merkle
Should also be more efficient due to not shifting as often.
* Tidy Mlsag
* Remove verify_rct_* from Mlsag
Both methods were ports from Monero, overtly specific without clear
documentation. They need to be added back in, with documentation, or included
in a node which provides the necessary further context for them to be naturally
understandable.
* Move mlsag/mod.rs to mlsag.rs
This should only be a folder if it has multiple files.
* Replace EcdhInfo terminology
The ECDH encrypted the amount, yet this struct contained the encrypted amount,
not some ECDH.
Also corrects the types on the original EcdhInfo struct.
* Correct handling of commitment masks when scanning
* Route read_array through read_raw_vec
* Misc lint
* Make a proper RctType enum
No longer caches RctType in the RctSignatures as well.
* Replace Vec<Bulletproofs> with Bulletproofs
Monero uses aggregated range proofs, so there's only ever one Bulletproof. This
is enforced with a consensus rule as well, making this safe.
As for why Monero uses a vec, it's probably due to the lack of variadic typing
used. Its effectively an Option for them, yet we don't need an Option since we
do have variadic typing (enums).
* Add necessary checks to Eventuality re: supported protocols
* Fix for block 202612 and fix merkel root calculations
* MLSAG (de)serialisation fix
ss_2_elements will not always be 2 as rct type 1 transactions are not enforced to have one input
* Revert "MLSAG (de)serialisation fix"
This reverts commit 5e710e0c96658092c6ecfe5e4ea5a9c3dbee3ab3.
here it checks number of MGs == number of inputs:
https://github.com/monero-project/monero/blob/0a1eaf26f9dd6b762c2582ee12603b2a4671c735/src/cryptonote_core/tx_verification_utils.cpp#L60-59
and here it checks for RctTypeFull number of MGs == 1:
https://github.com/monero-project/monero/blob/0a1eaf26f9dd6b762c2582ee12603b2a4671c735/src/ringct/rctSigs.cpp#L1325
so number of inputs == 1
so ss_2_elements == 2
* update `MlsagAggregate` comment
* cargo update
Resolves a yanked crate
* Move location of serai-client in Cargo.toml
---------
Co-authored-by: Luke Parker <lukeparker5132@gmail.com>
* Fix the known issue with the DSA
I wrote it to only select TXs with a timelock, not only TXs which are unlocked.
This most likely explains why it so heavily selected coinbases.
Also moves an InternalError which would've never been hit on mainnet, yet
technically isn't an invariant, to only exist when cfg(test).
* Add a bin to download a chain, over RPC, reserializing and hashing every item
Parallelized. Doesn't check the deserialization is correct. Does use distinct,
persistent HTTP clients.
* Correct how Monero integration tests are run
* Support multiple RPCs in the reserialize_chain bin
* Don't call get_height every block
* Modify get_transactions to split requests as to not hit the restricted RPC limits
* Meaningful changes from aggressive-clippy
I do want to enable a few specific lints, yet aggressive-clippy as a whole
isn't worthwhile.
* Extend reserialize_chain with CLSAG/BP(+) verification
* Remove spammy println from reserialize_chain
* Update reserialize_chain for v1 and migration TXs
Also always marks 0-amount inputs as RCT due to impossibility of non-RCT
0-amount outputs.
* Only deserialize RctSignatures where's there at least one input
This is only enforced by the Monero protocol due to a single check the mixRing
isn't empty in get_pre_mlsag_hash. The value in ensuring there's a least one
input is to ensure the safety of our rct_type functions, which determines the
RctType based off structural analysis (specifically, input data if
MlsagBorromean).
rct_type was technically safe without this. A 0-input transaction would be
mis-classified as RctFull/MlsagAggregate, which would then make the
RctSignatures invalid for being RctFull (requiring exactly one input) yet not
having inputs, meaning an invalid RctSignatures would be mis-classified yet
still invalid.
This just removes the risk of mis-classification in the first place, tightening
the library's safety.
* docs/Getting Started.md: cargo build --release --all-features
* Fix the known instance of #295
* Bind RocksDB into serai-db
* Split up tests in CI to avoid node storage limits
* Corrections to prior commit
* Again
I called git commit --amend without calling git add . again :(
* Update the flow for completed signing processes
Now, an on-chain transaction exists. This resolves some ambiguities and
provides greater coordination.
* Clean Polyseed code
* Final tweaks
* Correct no-std builds for Polyseed
* Again correct no-std
---------
Co-authored-by: Luke Parker <lukeparker5132@gmail.com>
Co-authored-by: GitHub Actions <unknown>
Co-authored-by: Boog900 <54e72d8a-345f-4599-bd90-c6b9bc7d0ec5@aleeas.com>
Co-authored-by: Boog900 <108027008+Boog900@users.noreply.github.com>
Co-authored-by: Steven Chang <stevenchang5000@gmail.com>
2023-07-16 11:25:17 +00:00
|
|
|
[[package]]
|
|
|
|
name = "password-hash"
|
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "346f04948ba92c43e8469c1ee6736c7563d71012b17d40745260fe106aac2166"
|
|
|
|
dependencies = [
|
|
|
|
"base64ct",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
add polyseed support (#257)
* add polyseed support
* fix pr comments
* fix tests
* Embed the mempool into the Blockchain
* Plan scheduled payments whenever outputs are received
The scheduler prior waited for the next series of payments to be added.
* Replace Tendermint step with sync_block
Step moved a step forward after an externally synced/added block. This created
a race condition to add the block between the sync process and the Tendermint
machine. Now that the block routes through Tendermint, there is no such race
condition.
* Finish binding Tendermint into Tributary and define a Tributary master object
* Add correction the last commit missed
* Add DoS limits to tributary and require provided transactions be ordered
* Fix the scheduler from dropping UTXOs when there weren't any payments
* Documentation and cargo update
* Add a dedicated db crate with a basic DB trait
It's needed by the processor and tributary (coordinator).
* Add a DB to Tributary
Adds support for reloading most of the blockchain.
* Reloaded provided transactions from the disk
Also resolves a race condition by asserting provided transactions must be
unique, allowing them to be safely provided multiple times.
* must_use annotations on DbTxn
* Support reloading the mempool from disk
* Add a NewSet event to validator-sets
Updates to the latest serai-dex/substrate due to depending on
10ccaca0eb498a2316bbf627d419b29b1a75933a.
* Add basic getters to tributary
* cargo update
* Update to the latest subxt
Writes a custom unsigned extrinic creator due to subxt having an internal error
with the scale metadata. While the code in our scope increased, it's much more
ergonomic to our usage. We may end up rewriting most of subxt, eventually.
* Make unsigned private due to unsafe calling potential
* Start defining the coordinator
* Merge AckBlock with Burns
Offers greater efficiency while reducing concerns re: atomicity.
* Correct processor flow to have the coordinator decide signing set/re-attempts
The signing set should be the first group to submit preprocesses to Tributary.
Re-attempts shouldn't be once every 30s, yet n blocks since the last relevant
message.
Removes the use of an async task/channel in the signer (and Substrate signer).
Also removes the need to be able to get the time from a coin's block, which was
a fragile system marked with a TODO already.
* cargo +nightly fmt
* cargo update
Since p256 now pulls in an extra crate with this update, the {k,p}256 imports
disable default-features to prevent growing the tree.
* Support extracting timestamps from blocks
* Make progres on handling NewSet events
Further bones out the coordinator.
* Resolve #245
* Have InInstructions track the latest block for a network in storage
* Fill out code for the rest of the Substrate events
* Clean up the Substrate block processing code
* Rename transaction file to tributary, add function for genesis
* Add a processor API to the coordinator
* Add extensive commentary on mutable to the processor's main file
Clearly establishes why consistency is guaranteed from a Rust borrow-checker
mindset. While there are plenty of... 'violations', they're clearly explained.
Hopefully, this method of thinking helps promote/ensure consistency in the
future.
* Move ConfirmKeyPair from key_gen to substrate
Clarifies the emitter and accordingly why its mutations are justified.
* Remove BatchSigned
SubstrateBlock's provision of the most recently acknowledged block has
equivalent information with the same latency. Accordingly, there's no need for
it.
* Add note to processor_messages
* Use a single txn for an entire coordinator message
Removes direct DB accesses whre possible. Documents the safety of the rest.
Does uncover one case of unsafety not previously noted.
* cargo update to remove usage of yanked crate
* Clarify safety of Scanner::block_number and KeyGen::keys
* Tweak ConfirmKeyPair to alleviate database requirements of coordinator
* Use an enum for Coin/NetworkId
It originally wasn't an enum so software which had yet to update before an
integration wouldn't error (as now enums are strictly typed). The strict typing
is preferable though.
* Code a method to determine the activation block before any block has consensus
[0; 32] is a magic for no block has been set yet due to this being the first
key pair. If [0; 32] is the latest finalized block, the processor determines
an activation block based on timestamps.
This doesn't use an Option for ergonomic reasons.
* automate whitespace & trimming test cases
* Save keys by their tweaked group_key
Keys are referred to by their tweaked versions. If a tweak was needed, keys
would fail to confirm.
* Use crypto-bigint's reduction in ed448
Achieves feasible performance in the ed448 which makes it potentially viable
for real world usage.
Accordingly prepares a new release, updating the README.
* Move the entirety of ed448 to Residue, offering a further 2-4x speedup
* Resolve #68
Notably speeds up monero-serai's build and CLSAG performance.
* Make MainDB into SubstrateDB
* Initial Tributary handling
* Add additional checks to key_gen/sign
There is the ability to cause state bloat by flooding Tributary.
KeyGen/Sign specifically shouldn't allow bloat since we check the
commitments/preprocesses/shares for validity. Accordingly, any invalid data
(such as bloat) should be detected.
It was posssible to place bloat after the valid data. Doing so would be
considered a valid KeyGen/Sign message, yet could add up to 50k kB per sign.
* Apply DKG TX handling code to all sign TXs
The existing code was almost entirely applicable. It just needed to be scoped
with an ID. While the handle function is now a bit convoluted, I don't see a
better option.
* Split FinalizedBlock into ExternalBlock and SeraiBlock
Also re-arranges their orders.
* Add support for multiple orderings in Provided
Necessary as our Tributary chains needed to agree when a Serai block has
occurred, and when a Monero block has occurred. Since those could happen at the
same time, some validators may put SeraiBlock before ExternalBlock and vice
versa, causing a chain halt. Now they can have distinct ordering queues.
* Slash on unrecognized ID
* ExternalBlock handler
* Add a SubstrateBlockAck message to the processor
When a Substrate block occurs, the coordinator is expected to emit
SubstrateBlock. This causes the processor to begin a variety of plans. The
processor now emits SubstrateBlockAck, explicitly listing all plan IDs, before
starting signing.
This lets the coordinator provide a SubstrateBlock transaction, and with it,
recognize all plan IDs as valid.
Prior, we would've had to have a spotty algorithm based upon the upcoming
Preprocess messages, or if we immediately provided the SubstrateBlock
transaction, then wait for the processor to inform us of the contained plans.
This creates an explicitly proper async flow not reliant on waiting for data
availability.
Alternatively, we could've replaced Preprocess with (Block, Vec<Preprocess>).
This would've been more efficient, yet also clunky due to the multiple usages
of the Preprocess message.
* Route the SubstrateBlock message, which is the last Tributary transaction type
* Add recent bloat checks added to signer to substrate_signer as well
* Add no_std support to transcript, dalek-ff-group, ed448, ciphersuite, multiexp, schnorr, and monero-generators
transcript, dalek-ff-group, ed449, and ciphersuite are all usable with no_std
alone. The rest additionally require alloc.
Part of #279.
* Add a test to the coordinator for running a Tributary
Impls a LocalP2p for testing.
Moves rebroadcasting into Tendermint, since it's what knows if a message is
fully valid + original.
Removes TributarySpec::validators() HashMap, as its non-determinism caused
different instances to have different round robin schedules. It was already
prior moved to a Vec for this issue, so I'm unsure why this remnant existed.
Also renames the GH no-std workflow from the prior commit.
* Add a test for Tributary
Further fleshes out the Tributary testing code.
* Test handling of DKG commitments transactions
* Add Transaction::sign.
While I don't love the introduction of empty_signed, it's practically fine.
* Tributary test wait_for_tx_inclusion function
* Additionally test DKGShares
* Handle adding new Tributaries
Removes last_block as an argument from Tendermint. It now loads from the DB as
needed. While slightly less performant, it's easiest and should be fine.
* Reload Tributaries
add_active_tributary writes the spec to disk before it returns, so even if the
VecDeque it pushes to isn't popped, the tributary will still be loaded on boot.
* Start handling P2P messages
This defines the tart of a very complex series of locks I'm really unhappy
with. At the same time, there's not immediately a better solution. This also
should work without issue.
* Clarify Arc RwLocks and sleeps in coordinator
* Send a heartbeat message when a Tributary falls behind
* cargo fmt
* cargo update
* Move json word lists to rs
Allows building the seed code without serde_json.
* Break coordinator main into multiple functions
Also moves from std::sync::RwLock to tokio::sync::RwLock to prevent wasting
cycles on spinning.
* Remove reliance on a blockchain read lock from block/commit
* Implement Tributary syncing
Also adds a forwards-lookup to the Tributary blockchain.
* Don't return from sync_block until the Tendermint machine returns if it's valid or not
We had a race condition where'd we be informed of blocks 1 .. 3, and
immediately add 1 .. 3. Because we immediately tried to add 2 after 1, it'd
fail since the tip was still the genesis, yet 2 needs the tip to be 1.
Adding a channel, while ugly, was the simplest way to accomplish this.
Also has any added block be broadcasted. Else there's a race condition where a
node which syncs up to the most recent block does so, yet fails to add the next
block when it's committed to.
* Test handle_p2p and Tributary syncing
Includes bug fixes.
* Tweak tests workflow
* Add a TributaryReader which doesn't require a borrow to operate
Reduces lock contention.
Additionally changes block_key to include the genesis. While not technically
needed, the lack of genesis introduced a side effect where any Tributary on the
the database could return the block of any other Tributary. While that wasn't a
security issue, returning it suggested it was on-chain when it wasn't. This may
have been usable to create issues.
* Document panic in FROST
* Document a pair of panics requiring 256 GB of RAM/4 GB of a context
* Add a UID function to messages
When we receive messages, we're provided with a message ID we can use to
prevent handling an item multiple times. That doesn't prevent us from *sending*
an item multiple times though. Thanks to the UID system, we can now not send if
already present.
Alternatively, we can remove the ordered message ID for just the UID, allowing
duplicates to be sent without issue, and handled on the receiving end.
* Initial code to handle messages from processors
* Document the processor/tributary/coordinator/serai flow
* Have Coordinator MainDb take a mutable borrow
* Update to substrate polkadot-v0.9.42
* Correct error message in ff-group-tests
* Update to May's nightly
Doesn't use the PR due to the needed changes.
* Support arbitrary RPC providers in monero-serai
Sets a clean path for no-std premised RPCs (buffers to an external RPC impl)/
Tor-based RPCs/client-side load balancing/...
* Correct processor's handling of the new Monero RPC code
* Correct Serai Dockerfile
* Publish ExternablBlock/SubstrateBlock, delay *Preprocess until ID acknowledged
Adds a channel for the Tributary scanner to communicate when an ID has been
acknowledged.
* Rename uid to intent
* Use U448 for Ed448 instead of U512
* Spawn a new async task for each block message
This probably should be done with n-long lived tasks, one per Tributary. While
this may not be suitably performant long-term (potential DoS vector), this at
least resolves the halting concerns.
* Move the coordinator to a n-processor design
* Ensure Tributary commits are minimal
* Properly get genesis for a Processor message
* Create a vote transaction upon GeneratedKeyPair
* Remove TODO about code de-duplication
It's infeasible to write a macro/function there. Does add a type alias which
makes things cleaner.
* Have coordinator publish batches to Substrate
* Implement MuSig key aggregation into DKG
Isn't spec compliant due to the lack of a spec to be compliant too.
Slight deviation from the paper by using a unique list instead of a multiset.
Closes #186, progresses #277.
* Correct 2/3rds definitions throughout the codebase
The prior formula failed for some values, such as 20.
20 / 3 = 6, * 2 = 12, + 1 = 13. 13 is 65%, not >= 67.
* cargo update
Resolves a yanked crate and removes some duplicated dependencies.
* Add a dedicated function to get a MuSig key
* Do the minimal amount of work for dkg to compile under no-std
The Substrate runtime requires access to the MuSig key aggregation function.
\#279 related.
* Use a MuSig signature to publish validator set key pairs to Serai
The processor/coordinator flow still has to be rewritten.
* Correct various no_std definitions
* Add a context to MuSig key aggregation
* Use proper messages for ValidatorSets/InInstructions pallet
Provides a DST, and associated metadata as beneficial.
Also utilizes MuSig's context to session-bind. Since set_keys_messages also
binds to set, this is semi-redundant, yet that's appreciated.
* Remove signed Substrate TXs from Coordinator
* Only scan v2 Monero TXs
* Fix for prior commit
* Ensure canonical points in the cross-group DLEq proof
* Fix incorrect sig_hash generation
sig_hash was used as a challenge. challenges should be of the form H(R, A, m).
These sig hashes were solely H(A, m), allowing trivial forgeries.
* cargo update
Resolves an openssl advisory and nets ~-8 crates.
* Build no-std tests with RISC-V 32 IMAC
Turns out wasm still has std, making it suboptimal to use here.
* Pin setup-protoc to v2.0.0
* Update to substrate polkadot-v0.9.43
* fix tributary sync test
* Slight terminology correction in sync test
Also correct a mistake from merging the most recent polkadot version.
* Update nightly
* Replace lazy_static with OnceLock inside monero-serai
lazy_static, if no_std environments were used, effectively required always
using spin locks. This resolves the ergonomics of that while adopting Rust std
code.
no_std does still use a spin based solution. Theoretically, we could use
atomics, yet writing our own Mutex wasn't a priority.
* no-std support for monero-serai (#311)
* Move monero-serai from std to std-shims, where possible
* no-std fixes
* Make the HttpRpc its own feature, thiserror only on std
* Drop monero-rs's epee for a homegrown one
We only need it for a single function. While I tried jeffro's, it didn't work
out of the box, had three unimplemented!s, and is no where near viable for
no_std.
Fixes #182, though should be further tested.
* no-std monero-serai
* Allow base58-monero via git
* cargo fmt
* Represent RCT amounts with None, not 0.
Fixes #282.
Does allow any v1 TXs which exist, and v2 miner-TXs, to specify Some(0). As far
as I can tell, both were/are theoreitcally possible.
* Add a message queue
This is intended to be a reliable transport between the processors and
coordinator. Since it'll be intranet only, it's written as never fail.
Primarily needs testing and a proper ID.
* cargo update
Resolves https://github.com/serai-dex/serai/security/dependabot/29
* Correct deny.toml with inclusion of message-queue
* Update nightly
* std-shims: six `Read` for &[u8]
* Use serai- prefixes on Serai-specific packages
Fixes deny.toml, also runs a minor cargo update shrinking the tree.
* Update monero-tests workflow to new name for the processor
* Correct depends for processor-messages
* Disable Rust caching
We hit the cache limit after just one or two builds, making it infeasible.
* cargo update
Resolves a yanked crate
* Move location of serai-client in Cargo.toml
* Monero: support for legacy transactions (#308)
* add mlsag
* fix last commit
* fix miner v1 txs
* fix non-miner v1 txs
* add borromean + fix mlsag
* add block hash calculations
* fix for the jokester that added unreduced scalars
to the borromean signature of
2368d846e671bf79a1f84c6d3af9f0bfe296f043f50cf17ae5e485384a53707b
* Add Borromean range proof verifying functionality
* Add MLSAG verifying functionality
* fmt & clippy :)
* update MLSAG, ss2_elements will always be 2
* Add MgSig proving
* Tidy block.rs
* Tidy Borromean, fix bugs in last commit, replace todo! with unreachable!
* Mark legacy EcdhInfo amount decryption as experimental
* Correct comments
* Write a new impl of the merkle algorithm
This one tries to be understandable.
* Only pull in things only needed for experimental when experimental
* Stop caching the Monero block hash now in processor that we have Block::hash
* Corrections for recent processor commit
* Use a clearer algorithm for the merkle
Should also be more efficient due to not shifting as often.
* Tidy Mlsag
* Remove verify_rct_* from Mlsag
Both methods were ports from Monero, overtly specific without clear
documentation. They need to be added back in, with documentation, or included
in a node which provides the necessary further context for them to be naturally
understandable.
* Move mlsag/mod.rs to mlsag.rs
This should only be a folder if it has multiple files.
* Replace EcdhInfo terminology
The ECDH encrypted the amount, yet this struct contained the encrypted amount,
not some ECDH.
Also corrects the types on the original EcdhInfo struct.
* Correct handling of commitment masks when scanning
* Route read_array through read_raw_vec
* Misc lint
* Make a proper RctType enum
No longer caches RctType in the RctSignatures as well.
* Replace Vec<Bulletproofs> with Bulletproofs
Monero uses aggregated range proofs, so there's only ever one Bulletproof. This
is enforced with a consensus rule as well, making this safe.
As for why Monero uses a vec, it's probably due to the lack of variadic typing
used. Its effectively an Option for them, yet we don't need an Option since we
do have variadic typing (enums).
* Add necessary checks to Eventuality re: supported protocols
* Fix for block 202612 and fix merkel root calculations
* MLSAG (de)serialisation fix
ss_2_elements will not always be 2 as rct type 1 transactions are not enforced to have one input
* Revert "MLSAG (de)serialisation fix"
This reverts commit 5e710e0c96658092c6ecfe5e4ea5a9c3dbee3ab3.
here it checks number of MGs == number of inputs:
https://github.com/monero-project/monero/blob/0a1eaf26f9dd6b762c2582ee12603b2a4671c735/src/cryptonote_core/tx_verification_utils.cpp#L60-59
and here it checks for RctTypeFull number of MGs == 1:
https://github.com/monero-project/monero/blob/0a1eaf26f9dd6b762c2582ee12603b2a4671c735/src/ringct/rctSigs.cpp#L1325
so number of inputs == 1
so ss_2_elements == 2
* update `MlsagAggregate` comment
* cargo update
Resolves a yanked crate
* Move location of serai-client in Cargo.toml
---------
Co-authored-by: Luke Parker <lukeparker5132@gmail.com>
* Fix the known issue with the DSA
I wrote it to only select TXs with a timelock, not only TXs which are unlocked.
This most likely explains why it so heavily selected coinbases.
Also moves an InternalError which would've never been hit on mainnet, yet
technically isn't an invariant, to only exist when cfg(test).
* Add a bin to download a chain, over RPC, reserializing and hashing every item
Parallelized. Doesn't check the deserialization is correct. Does use distinct,
persistent HTTP clients.
* Correct how Monero integration tests are run
* Support multiple RPCs in the reserialize_chain bin
* Don't call get_height every block
* Modify get_transactions to split requests as to not hit the restricted RPC limits
* Meaningful changes from aggressive-clippy
I do want to enable a few specific lints, yet aggressive-clippy as a whole
isn't worthwhile.
* Extend reserialize_chain with CLSAG/BP(+) verification
* Remove spammy println from reserialize_chain
* Update reserialize_chain for v1 and migration TXs
Also always marks 0-amount inputs as RCT due to impossibility of non-RCT
0-amount outputs.
* Only deserialize RctSignatures where's there at least one input
This is only enforced by the Monero protocol due to a single check the mixRing
isn't empty in get_pre_mlsag_hash. The value in ensuring there's a least one
input is to ensure the safety of our rct_type functions, which determines the
RctType based off structural analysis (specifically, input data if
MlsagBorromean).
rct_type was technically safe without this. A 0-input transaction would be
mis-classified as RctFull/MlsagAggregate, which would then make the
RctSignatures invalid for being RctFull (requiring exactly one input) yet not
having inputs, meaning an invalid RctSignatures would be mis-classified yet
still invalid.
This just removes the risk of mis-classification in the first place, tightening
the library's safety.
* docs/Getting Started.md: cargo build --release --all-features
* Fix the known instance of #295
* Bind RocksDB into serai-db
* Split up tests in CI to avoid node storage limits
* Corrections to prior commit
* Again
I called git commit --amend without calling git add . again :(
* Update the flow for completed signing processes
Now, an on-chain transaction exists. This resolves some ambiguities and
provides greater coordination.
* Clean Polyseed code
* Final tweaks
* Correct no-std builds for Polyseed
* Again correct no-std
---------
Co-authored-by: Luke Parker <lukeparker5132@gmail.com>
Co-authored-by: GitHub Actions <unknown>
Co-authored-by: Boog900 <54e72d8a-345f-4599-bd90-c6b9bc7d0ec5@aleeas.com>
Co-authored-by: Boog900 <108027008+Boog900@users.noreply.github.com>
Co-authored-by: Steven Chang <stevenchang5000@gmail.com>
2023-07-16 11:25:17 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
2023-03-28 08:38:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pasta_curves"
|
|
|
|
version = "0.5.1"
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
source = "git+https://github.com/kayabaNerve/pasta_curves?rev=a46b5be95cacbff54d06aad8d3bbcba42e05d616#a46b5be95cacbff54d06aad8d3bbcba42e05d616"
|
2023-03-28 08:38:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"blake2b_simd",
|
2023-07-28 03:38:04 +00:00
|
|
|
"ff",
|
|
|
|
"group",
|
2023-03-28 08:38:01 +00:00
|
|
|
"lazy_static",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-03-28 08:38:01 +00:00
|
|
|
"static_assertions",
|
|
|
|
"subtle",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"zeroize",
|
2023-03-28 08:38:01 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "paste"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.0.15"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "57c0d7b74b563b49d38dae00a0c37d4d6de9b432382b2892f0574ddcae73fd0a"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2024-09-05 20:30:27 +00:00
|
|
|
[[package]]
|
|
|
|
name = "patchable-async-sleep"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pbkdf2"
|
|
|
|
version = "0.11.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "83a0692ec44e4cf1ef28ca317f14f8f07da2d95ec3fa01f86e4467b725e60917"
|
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pbkdf2"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "0.12.2"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "f8ed6a7761f76e3b9f92dfb0a60a6a6477c61024b775147ff0973a02653abaf2"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"hmac",
|
2023-09-12 11:47:03 +00:00
|
|
|
"password-hash",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-03-25 04:45:33 +00:00
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pem"
|
|
|
|
version = "1.1.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a8835c273a76a90455d7344889b0964598e3316e2a79ede8e36f16bdcf2228b8"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.13.1",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "percent-encoding"
|
2023-11-28 07:29:50 +00:00
|
|
|
version = "2.3.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-28 07:29:50 +00:00
|
|
|
checksum = "e3148f5046208a5d56bcfc03053e3ca6334e51da8dfb19b6cdc8b306fae3283e"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
name = "pest"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "2.7.11"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "cd53dff83f26735fdc1ca837098ccf133605d794cdae66acfc2bfac3ec809d95"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"memchr",
|
|
|
|
"thiserror",
|
|
|
|
"ucd-trie",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
name = "petgraph"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.6.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "b4c5cc86750666a3ed20bdaf5ca2a0344f9c67674cae0515bec2da16fbaa47db"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"fixedbitset",
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-project"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "1.1.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "b6bf43b791c5b9e34c3d182969b4abb522f9343702850a2e57f460d00d09b4b3"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"pin-project-internal",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-project-internal"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "1.1.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "2f38a4412a78282e09a2cf38d195ea5420d15ba0602cb375210efbc877243965"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-project-lite"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "0.2.14"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "bda66fc9667c18cb2758a2ac84d1167245054bcf85d5d1aaa6923f45801bdd02"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pin-utils"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8b870d8c151b6f2fb93e84a13146138f05d02ed11c7e7c54f8826aaaf7c9f184"
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "pkcs8"
|
2023-04-08 08:44:28 +00:00
|
|
|
version = "0.10.2"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-08 08:44:28 +00:00
|
|
|
checksum = "f950b2377845cebe5cf8b5165cb3cc1a5e0fa5cfa3e1f7f55707d8fd82e0a7b7"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"der",
|
|
|
|
"spki",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "pkg-config"
|
2024-02-25 23:37:15 +00:00
|
|
|
version = "0.3.30"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-25 23:37:15 +00:00
|
|
|
checksum = "d231b230927b5e4ad203db57bbcbee2802f6bce620b1e4a9024a07d94e2907ec"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "polling"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "3.7.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "5e6a007746f34ed64099e88783b0ae369eaa3da6392868ba262e2af9b8fbaea1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-03-11 09:49:05 +00:00
|
|
|
"concurrent-queue",
|
2024-03-27 04:17:04 +00:00
|
|
|
"hermit-abi",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
|
|
|
"tracing",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.52.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "poly1305"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.8.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "8159bd90725d2df49889a078b54f4f79e87f1f8a8444194cdca81d38f5393abf"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cpufeatures",
|
2023-04-08 08:44:28 +00:00
|
|
|
"opaque-debug",
|
2023-07-28 03:38:04 +00:00
|
|
|
"universal-hash",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
[[package]]
|
|
|
|
name = "polyseed"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"hex",
|
|
|
|
"pbkdf2 0.12.2",
|
|
|
|
"rand_core",
|
|
|
|
"sha3",
|
|
|
|
"std-shims",
|
|
|
|
"subtle",
|
|
|
|
"thiserror",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "polyval"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "0.6.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "9d1fe60d06143b2430aa532c94cfe9e29783047f06c0d7fd359a9a51b729fa25"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"cpufeatures",
|
2023-04-08 08:44:28 +00:00
|
|
|
"opaque-debug",
|
2023-07-28 03:38:04 +00:00
|
|
|
"universal-hash",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-10-19 04:02:27 +00:00
|
|
|
[[package]]
|
|
|
|
name = "powerfmt"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "439ee305def115ba05938db6eb1644ff94165c5ab5e9420d1c1bcedbba909391"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ppv-lite86"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.20"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "77957b295656769bb8ad2b6a6b09d897d94f05c41b069aede1fcdaa675eaea04"
|
|
|
|
dependencies = [
|
|
|
|
"zerocopy",
|
|
|
|
]
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "predicates"
|
2023-01-04 08:17:36 +00:00
|
|
|
version = "2.1.5"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-01-04 08:17:36 +00:00
|
|
|
checksum = "59230a63c37f3e18569bdb90e4a89cbf5bf8b06fea0b84e65ea10cc4df47addd"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"difflib",
|
|
|
|
"float-cmp",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"itertools 0.10.5",
|
2022-10-20 05:05:36 +00:00
|
|
|
"normalize-line-endings",
|
|
|
|
"predicates-core",
|
|
|
|
"regex",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "predicates-core"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.0.8"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "ae8177bee8e75d6846599c6b9ff679ed51e882816914eec639944d7c9aa11931"
|
2022-10-20 05:05:36 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "predicates-tree"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "1.0.11"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "41b740d195ed3166cd147c8047ec98db0e22ec019eb8eeb76d343b795304fb13"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
|
|
|
"predicates-core",
|
|
|
|
"termtree",
|
|
|
|
]
|
|
|
|
|
2022-11-11 04:59:20 +00:00
|
|
|
[[package]]
|
|
|
|
name = "prettyplease"
|
2023-03-16 23:37:32 +00:00
|
|
|
version = "0.1.25"
|
2022-11-11 04:59:20 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-16 23:37:32 +00:00
|
|
|
checksum = "6c8646e95016a7a6c4adea95bafa8a16baab64b583356217f2c85db4a39d9a86"
|
2022-11-11 04:59:20 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-11-11 04:59:20 +00:00
|
|
|
]
|
|
|
|
|
2024-09-15 16:04:57 +00:00
|
|
|
[[package]]
|
|
|
|
name = "prettyplease"
|
|
|
|
version = "0.2.22"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "479cf940fbbb3426c32c5d5176f62ad57549a0bb84773423ba8be9d089f5faba"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"syn 2.0.77",
|
|
|
|
]
|
|
|
|
|
2023-03-06 13:22:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "primeorder"
|
2023-11-20 04:52:32 +00:00
|
|
|
version = "0.13.6"
|
2023-04-11 13:23:54 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-20 04:52:32 +00:00
|
|
|
checksum = "353e1ca18966c16d9deb1c69278edbc5f194139612772bd9537af60ac231e1e6"
|
2023-03-06 13:22:04 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"elliptic-curve",
|
2023-03-06 13:22:04 +00:00
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "primitive-types"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.12.2"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "0b34d9fd68ae0b74a41b21c03c2f62847aa0ffea044eee893b4c140b37e244e2"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
2023-07-24 08:53:59 +00:00
|
|
|
"fixed-hash",
|
2022-10-20 05:05:36 +00:00
|
|
|
"impl-codec",
|
2023-01-05 03:52:41 +00:00
|
|
|
"impl-serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
"scale-info",
|
|
|
|
"uint",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-crate"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "1.3.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "7f4c021e1093a56626774e81216a4ce732a735e5bad4868a03f3ed65ca0c3919"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"once_cell",
|
2023-11-25 09:01:11 +00:00
|
|
|
"toml_edit 0.19.15",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-crate"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "3.2.0"
|
2023-11-25 09:01:11 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "8ecf48c7ca261d60b74ab1a7b20da18bede46776b2e55535cb958eb595c5fa7b"
|
2023-11-25 09:01:11 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"toml_edit 0.22.20",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-error"
|
|
|
|
version = "1.0.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "da25490ff9892aab3fcf7c36f08cfb902dd3e71ca0f9f9517bea02a73a5ce38c"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro-error-attr",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
"version_check",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-error-attr"
|
|
|
|
version = "1.0.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a1be40180e52ecc98ad80b184934baf3d0d29f979574e439af5a55274b35f869"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"version_check",
|
|
|
|
]
|
|
|
|
|
2023-05-01 07:17:37 +00:00
|
|
|
[[package]]
|
|
|
|
name = "proc-macro-warning"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.4.2"
|
2023-05-01 07:17:37 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "3d1eaa7fa0aa1929ffdf7eeb6eac234dde6268914a14ad44d23521ab6a9b258e"
|
2023-05-01 07:17:37 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-05-01 07:17:37 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "proc-macro2"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.0.86"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "5e719e8df665df0d1c8fbfd238015744736151d4445ec0836b8e628aae103b77"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"unicode-ident",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "prometheus"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.13.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "3d33c28a30771f7f96db69893f78b857f7450d7e0237e9c8fc6427a81bae7ed1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"fnv",
|
|
|
|
"lazy_static",
|
|
|
|
"memchr",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "prometheus-client"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.21.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "3c99afa9a01501019ac3a14d71d9f94050346f55ca471ce90c799a15c58f61e2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"dtoa",
|
2022-10-20 05:05:36 +00:00
|
|
|
"itoa",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-06-28 18:57:58 +00:00
|
|
|
"prometheus-client-derive-encode",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2023-06-28 18:57:58 +00:00
|
|
|
name = "prometheus-client-derive-encode"
|
2023-08-15 09:39:23 +00:00
|
|
|
version = "0.4.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-15 09:39:23 +00:00
|
|
|
checksum = "440f724eba9f6996b75d63681b0a92b06947f1457076d503a4d2e2c8f56442b8"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "proptest"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.5.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "b4c2511913b88df1637da85cc8d96ec8e43a3f8bb8ccb71ee1ac240d6f3df58d"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"bit-set",
|
|
|
|
"bit-vec",
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"lazy_static",
|
|
|
|
"num-traits",
|
|
|
|
"rand",
|
|
|
|
"rand_chacha",
|
|
|
|
"rand_xorshift",
|
2024-06-13 19:57:08 +00:00
|
|
|
"regex-syntax 0.8.4",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"rusty-fork",
|
|
|
|
"tempfile",
|
|
|
|
"unarray",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "prost"
|
2023-04-14 01:05:18 +00:00
|
|
|
version = "0.11.9"
|
2022-09-29 18:33:09 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-14 01:05:18 +00:00
|
|
|
checksum = "0b82eaa1d779e9a4bc1c3217db8ffbeabaae1dca241bf70183242128d48681cd"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
2022-10-20 05:05:36 +00:00
|
|
|
"prost-derive",
|
2022-09-29 18:33:09 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "prost-build"
|
2023-04-14 01:05:18 +00:00
|
|
|
version = "0.11.9"
|
2022-09-29 18:33:09 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-14 01:05:18 +00:00
|
|
|
checksum = "119533552c9a7ffacc21e099c24a0ac8bb19c2a2a3f363de84cd9b844feab270"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.4.1",
|
|
|
|
"itertools 0.10.5",
|
2022-09-29 18:33:09 +00:00
|
|
|
"lazy_static",
|
|
|
|
"log",
|
|
|
|
"multimap",
|
|
|
|
"petgraph",
|
2024-09-15 16:04:57 +00:00
|
|
|
"prettyplease 0.1.25",
|
2022-10-20 05:05:36 +00:00
|
|
|
"prost",
|
|
|
|
"prost-types",
|
2022-07-16 21:49:35 +00:00
|
|
|
"regex",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tempfile",
|
|
|
|
"which",
|
|
|
|
]
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "prost-derive"
|
2023-04-14 01:05:18 +00:00
|
|
|
version = "0.11.9"
|
2022-09-29 18:33:09 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-14 01:05:18 +00:00
|
|
|
checksum = "e5d2d8d10f3c6ded6da8b05b5fb3b8a5082514344d56c9f871412d29b4e075b4"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"itertools 0.10.5",
|
2022-09-29 18:33:09 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-09-29 18:33:09 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "prost-types"
|
2023-04-14 01:05:18 +00:00
|
|
|
version = "0.11.9"
|
2022-09-29 18:33:09 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-14 01:05:18 +00:00
|
|
|
checksum = "213622a1460818959ac1181aaeb2dc9c7f63df720db7d788b3e24eacd1983e13"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
2022-10-20 05:05:36 +00:00
|
|
|
"prost",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "psm"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.23"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "aa37f80ca58604976033fae9515a8a2989fc13797d953f7c04fb8fa36a11f205"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "quick-error"
|
|
|
|
version = "1.2.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a1d01941d82fa2ab50be1e79e6714289dd7cde78eba4c074bc5a4374f650dfe0"
|
|
|
|
|
2023-03-16 23:37:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "quick-protobuf"
|
|
|
|
version = "0.8.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9d6da84cc204722a989e01ba2f6e1e276e190f22263d0cb6ce8526fcdb0d2e1f"
|
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
]
|
|
|
|
|
2023-06-28 18:57:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "quick-protobuf-codec"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.2.0"
|
2023-06-28 18:57:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "f8ededb1cd78531627244d51dd0c7139fbe736c7d57af0092a76f0ffb2f56e98"
|
2023-06-28 18:57:58 +00:00
|
|
|
dependencies = [
|
|
|
|
"asynchronous-codec",
|
|
|
|
"bytes",
|
|
|
|
"quick-protobuf",
|
|
|
|
"thiserror",
|
|
|
|
"unsigned-varint",
|
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "quinn"
|
|
|
|
version = "0.10.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8cc2c5017e4b43d5995dcea317bc46c1e09404c0a9664d2908f7f02dfe943d75"
|
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures-io",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2023-08-25 03:55:47 +00:00
|
|
|
"quinn-proto",
|
|
|
|
"quinn-udp",
|
|
|
|
"rustc-hash",
|
2024-05-21 10:09:04 +00:00
|
|
|
"rustls 0.21.12",
|
2023-08-25 03:55:47 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "quinn-proto"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.10.6"
|
2023-08-25 03:55:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "141bf7dfde2fbc246bfd3fe12f2455aa24b0fbd9af535d8c86c7bd1381ff2b1a"
|
2023-08-25 03:55:47 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"rand",
|
2023-11-06 12:19:55 +00:00
|
|
|
"ring 0.16.20",
|
2023-08-25 03:55:47 +00:00
|
|
|
"rustc-hash",
|
2024-05-21 10:09:04 +00:00
|
|
|
"rustls 0.21.12",
|
2023-08-25 03:55:47 +00:00
|
|
|
"slab",
|
|
|
|
"thiserror",
|
|
|
|
"tinyvec",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "quinn-udp"
|
|
|
|
version = "0.4.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "055b4e778e8feb9f93c4e439f71dc2156ef13360b432b799e179a8c4cdf0b1d7"
|
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"libc",
|
2024-05-21 10:09:04 +00:00
|
|
|
"socket2 0.5.7",
|
2023-08-25 03:55:47 +00:00
|
|
|
"tracing",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2023-08-25 03:55:47 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "quote"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.37"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "b5b9d34b8991d19d98081b46eacdd8eb58c6f2b201139f7c5f643cc155a633af"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "radium"
|
|
|
|
version = "0.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "dc33ff2d4973d518d823d61aa239014831e521c75da58e3df4840d3f47749d09"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand"
|
|
|
|
version = "0.8.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "34af8d1a0e25924bc5b7c43c079c942339d8f0a8b57c39049bef581b46327404"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand_chacha",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_chacha"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e6c10a63a0fa32252be49d21e7709d4d4baf8d231c2dbce1eaa8141b9b127d88"
|
|
|
|
dependencies = [
|
|
|
|
"ppv-lite86",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_core"
|
2022-09-18 19:30:38 +00:00
|
|
|
version = "0.6.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-09-18 19:30:38 +00:00
|
|
|
checksum = "ec0be4795e2f6a28069bec0b5ff3e2ac9bafc99e6a9a7dc3547996c5c816922c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"getrandom",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_distr"
|
|
|
|
version = "0.4.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "32cb0b9bc82b0a0876c2dd994a7e7a2683d3e7390ca40e6886785ef0c7e3ee31"
|
|
|
|
dependencies = [
|
|
|
|
"num-traits",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rand_pcg"
|
|
|
|
version = "0.3.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "59cad018caf63deb318e5a4586d99a24424a364f40f1e5778c29aca23f4fc73e"
|
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rand_xorshift"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d25bf25ec5ae4a3f1b92f929810509a2f53d7dca2f50b794ff57e3face536c8f"
|
|
|
|
dependencies = [
|
|
|
|
"rand_core",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rawpointer"
|
|
|
|
version = "0.2.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "60a357793950651c4ed0f3f52338f53b2f809f32d83a07f72909fa13e4c6c1e3"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rayon"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "1.10.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "b418a60154510ca1a002a752ca9714984e21e4241e804d32555251faf8b78ffa"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
"rayon-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rayon-core"
|
2024-01-19 16:44:49 +00:00
|
|
|
version = "1.12.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-19 16:44:49 +00:00
|
|
|
checksum = "1465873a3dfdaa8ae7cb14b4383657caab0b3e8a0aa9ae8e04b044854c8dfce2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"crossbeam-deque",
|
|
|
|
"crossbeam-utils",
|
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rcgen"
|
|
|
|
version = "0.10.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ffbe84efe2f38dea12e9bfc1f65377fdf03e53a18cb3b995faedf7934c7e785b"
|
|
|
|
dependencies = [
|
|
|
|
"pem",
|
2023-11-06 12:19:55 +00:00
|
|
|
"ring 0.16.20",
|
2023-09-12 11:47:03 +00:00
|
|
|
"time",
|
2023-08-25 03:55:47 +00:00
|
|
|
"yasna",
|
|
|
|
]
|
|
|
|
|
2023-10-19 04:03:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "redox_syscall"
|
2024-07-18 19:18:08 +00:00
|
|
|
version = "0.5.3"
|
2023-10-19 04:03:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-18 19:18:08 +00:00
|
|
|
checksum = "2a908a6e00f1fdd0dfd9c0eb08ce85126f6d8bbda50017e74bc4a4b7d4a926a4"
|
2023-10-19 04:03:58 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
2023-10-19 04:03:58 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "redox_users"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.4.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "ba009ff324d1fc1b900bd1fdb31564febe58a8ccc8a6fdbb93b543d33b13ca43"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"getrandom",
|
2024-05-21 12:07:32 +00:00
|
|
|
"libredox",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ref-cast"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.0.23"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "ccf0a6f84d5f1d581da8b41b47ec8600871962f2a528115b542b362d4b744931"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"ref-cast-impl",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ref-cast-impl"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.0.23"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "bcc303e793d3734489387d205e9b186fac9c6cfacedd98cbb2e8a5943595f3e6"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "regalloc2"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.9.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "ad156d539c879b7a24a363a2016d77961786e71f48f2e2fc8302a92abd2429a6"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-08-23 02:06:06 +00:00
|
|
|
"hashbrown 0.13.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-08-23 02:06:06 +00:00
|
|
|
"rustc-hash",
|
2022-07-16 21:49:35 +00:00
|
|
|
"slice-group-by",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "regex"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.10.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "4219d74c6b67a3654a9fbebc4b419e22126d13d2f3c4a07ee0cb61ff79a79619"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-19 02:30:55 +00:00
|
|
|
"aho-corasick",
|
2022-07-16 21:49:35 +00:00
|
|
|
"memchr",
|
2024-06-13 19:57:08 +00:00
|
|
|
"regex-automata 0.4.7",
|
|
|
|
"regex-syntax 0.8.4",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "regex-automata"
|
|
|
|
version = "0.1.10"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6c230d73fb8d8c1b9c0b3135c5142a8acee3a0558fb8db5cf1cb65f8d7862132"
|
|
|
|
dependencies = [
|
2023-04-23 23:21:24 +00:00
|
|
|
"regex-syntax 0.6.29",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-07-19 02:30:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "regex-automata"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.4.7"
|
2023-07-19 02:30:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "38caf58cc5ef2fed281f89292ef23f6365465ed9a41b7a7754eb4e26496c92df"
|
2023-07-19 02:30:55 +00:00
|
|
|
dependencies = [
|
|
|
|
"aho-corasick",
|
|
|
|
"memchr",
|
2024-06-13 19:57:08 +00:00
|
|
|
"regex-syntax 0.8.4",
|
2023-07-19 02:30:55 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "regex-syntax"
|
2023-03-25 04:45:33 +00:00
|
|
|
version = "0.6.29"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-25 04:45:33 +00:00
|
|
|
checksum = "f162c6dd7b008981e4d40210aca20b4bd0f9b60ca9271061b07f78537722f2e1"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-10-19 04:02:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "regex-syntax"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.8.4"
|
2023-10-19 04:02:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "7a66a03ae7c801facd77a29370b4faec201768915ac14a721ba36f20bc9c209b"
|
2023-10-19 04:02:55 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "resolv-conf"
|
|
|
|
version = "0.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "52e44394d2086d010551b14b53b1f24e31647570cd1deb0379e2c21b329aba00"
|
|
|
|
dependencies = [
|
|
|
|
"hostname",
|
|
|
|
"quick-error",
|
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rfc6979"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f8dd2a808d456c4a54e300a23e9f5a67e122c3024119acbfd73e3bf664491cb2"
|
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"hmac",
|
2023-03-25 04:45:33 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ring"
|
|
|
|
version = "0.16.20"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3053cf52e236a3ed746dfc745aa9cacf1b791d846bdaf412f60a8d7d6e17c8fc"
|
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"libc",
|
|
|
|
"once_cell",
|
2023-06-29 01:16:33 +00:00
|
|
|
"spin 0.5.2",
|
2023-11-06 12:19:55 +00:00
|
|
|
"untrusted 0.7.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"web-sys",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
2023-11-06 12:19:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ring"
|
2024-02-25 23:37:15 +00:00
|
|
|
version = "0.17.8"
|
2023-11-06 12:19:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-25 23:37:15 +00:00
|
|
|
checksum = "c17fa4cb658e3583423e915b9f3acc01cceaee1860e33d59ebae66adc3a2dc0d"
|
2023-11-06 12:19:55 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
2024-02-25 23:37:15 +00:00
|
|
|
"cfg-if",
|
2023-11-06 12:19:55 +00:00
|
|
|
"getrandom",
|
|
|
|
"libc",
|
|
|
|
"spin 0.9.8",
|
|
|
|
"untrusted 0.9.0",
|
2024-02-25 23:37:15 +00:00
|
|
|
"windows-sys 0.52.0",
|
2023-11-06 12:19:55 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ripemd"
|
2022-09-29 18:33:09 +00:00
|
|
|
version = "0.1.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-09-29 18:33:09 +00:00
|
|
|
checksum = "bd124222d17ad93a644ed9d011a40f4fb64aa54275c08cc216524a9ea82fb09f"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rlp"
|
2022-10-22 01:40:50 +00:00
|
|
|
version = "0.5.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-10-22 01:40:50 +00:00
|
|
|
checksum = "bb919243f34364b6bd2fc10ef797edbfa75f33c252e7998527479c6d6b47e1ec"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"rustc-hex",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rocksdb"
|
2023-06-28 18:57:58 +00:00
|
|
|
version = "0.21.0"
|
2024-03-09 06:58:58 +00:00
|
|
|
dependencies = [
|
|
|
|
"rocksdb 0.22.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rocksdb"
|
|
|
|
version = "0.22.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-09 06:58:58 +00:00
|
|
|
checksum = "6bd13e55d6d7b8cd0ea569161127567cd587676c99f4472f779a0279aa60a7a7"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"librocksdb-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rpassword"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "7.3.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "80472be3c897911d0137b2d2b9055faf6eeac5b14e324073d83bc17b191d7e3f"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
2022-12-07 22:56:53 +00:00
|
|
|
"rtoolbox",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rtnetlink"
|
|
|
|
version = "0.10.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "322c53fd76a18698f1c27381d58091de3a043d356aa5bd0d510608b565f469a0"
|
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"log",
|
|
|
|
"netlink-packet-route",
|
|
|
|
"netlink-proto",
|
2023-03-26 12:43:01 +00:00
|
|
|
"nix",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
2023-01-16 15:42:31 +00:00
|
|
|
"tokio",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-12-07 22:56:53 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rtoolbox"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.0.2"
|
2022-12-07 22:56:53 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "c247d24e63230cdb56463ae328478bd5eac8b8faa8c69461a77e8e323afac90e"
|
2022-12-07 22:56:53 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-12-07 22:56:53 +00:00
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ruint"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "1.12.3"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "2c3cc4c2511671f327125da14133d0c5c5d137f006a1017a16f557bc85b16286"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"alloy-rlp",
|
|
|
|
"ark-ff 0.3.0",
|
|
|
|
"ark-ff 0.4.2",
|
|
|
|
"bytes",
|
|
|
|
"fastrlp",
|
|
|
|
"num-bigint",
|
|
|
|
"num-traits",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"primitive-types",
|
|
|
|
"proptest",
|
|
|
|
"rand",
|
|
|
|
"rlp",
|
|
|
|
"ruint-macro",
|
|
|
|
"serde",
|
|
|
|
"valuable",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ruint-macro"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "1.2.1"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "48fd7bd8a6377e15ad9d42a8ec25371b94ddc67abe7c8b9127bec79bebaaae18"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustc-demangle"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.1.24"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "719b953e2095829ee67db738b3bfa9fa368c94900df327b3f07fe6e794d2fe1f"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustc-hash"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "08d43f7aa6b08d49f382cde6a7982047c3426db949b1424bc4b7ec9ae12c6ce2"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustc-hex"
|
|
|
|
version = "2.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3e75f6a532d0fd9f7f13144f392b6ad56a32696bfcd9c78f797f16bbb6f072d6"
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustc_version"
|
|
|
|
version = "0.3.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f0dfe2087c51c460008730de8b57e6a320782fbfb312e1f4d520e6c6fae155ee"
|
|
|
|
dependencies = [
|
|
|
|
"semver 0.11.0",
|
|
|
|
]
|
|
|
|
|
2022-07-17 01:06:54 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustc_version"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.4.1"
|
2022-07-17 01:06:54 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "cfcb3a22ef46e85b45de6ee7e79d063319ebb6594faafcf1c225ea92ab6e9b92"
|
2022-07-17 01:06:54 +00:00
|
|
|
dependencies = [
|
2024-05-21 10:09:04 +00:00
|
|
|
"semver 1.0.23",
|
2022-07-17 01:06:54 +00:00
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rusticata-macros"
|
|
|
|
version = "4.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "faf0c4a6ece9950b9abdb62b1cfcf2a68b3b67a10ba445b3bb85be2a293d0632"
|
|
|
|
dependencies = [
|
|
|
|
"nom",
|
|
|
|
]
|
|
|
|
|
2023-07-02 00:27:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustix"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.38.36"
|
2023-07-02 00:27:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "3f55e80d50763938498dd5ebb18647174e0c76dc38c5505294bb224624f30f36"
|
2023-07-02 00:27:03 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
2023-07-02 00:27:03 +00:00
|
|
|
"errno",
|
|
|
|
"libc",
|
2023-11-22 06:24:17 +00:00
|
|
|
"linux-raw-sys",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.52.0",
|
2023-07-02 00:27:03 +00:00
|
|
|
]
|
|
|
|
|
2023-06-22 10:25:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustls"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.21.12"
|
2023-06-22 10:25:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "3f56a14d1f48b391359b22f731fd4bd7e43c97f3c50eee276f3aa09c94784d3e"
|
2023-06-22 10:25:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"log",
|
2024-02-25 23:37:15 +00:00
|
|
|
"ring 0.17.8",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-webpki 0.101.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"sct",
|
2023-06-22 10:25:30 +00:00
|
|
|
]
|
|
|
|
|
2024-01-17 00:32:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustls"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.23.12"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "c58f8c84392efc0a126acce10fa59ff7b3d2ac06ab451a33f2741989b806b044"
|
2024-01-17 00:32:30 +00:00
|
|
|
dependencies = [
|
2024-03-27 04:17:04 +00:00
|
|
|
"once_cell",
|
2024-02-25 23:37:15 +00:00
|
|
|
"ring 0.17.8",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-pki-types",
|
2024-09-05 21:03:23 +00:00
|
|
|
"rustls-webpki 0.102.7",
|
2024-01-17 00:32:30 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustls-native-certs"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "fcaf18a4f2be7326cd874a5fa579fae794320a0f388d365dca7e480e55f83f8a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"openssl-probe",
|
|
|
|
"rustls-pemfile",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-pki-types",
|
2022-07-16 21:49:35 +00:00
|
|
|
"schannel",
|
|
|
|
"security-framework",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "rustls-pemfile"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "2.1.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "196fe16b00e106300d3e45ecfcb764fa292a535d7326a29a5875c579c7417425"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-05-21 10:09:04 +00:00
|
|
|
"base64 0.22.1",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-pki-types",
|
2023-06-22 10:25:30 +00:00
|
|
|
]
|
|
|
|
|
2024-01-17 00:32:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustls-pki-types"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.8.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "fc0a2ce646f8655401bb81e7927b812614bd5d91dbc968696be50603510fcaf0"
|
2024-01-17 00:32:30 +00:00
|
|
|
|
2023-07-28 03:38:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustls-webpki"
|
2023-11-06 12:19:55 +00:00
|
|
|
version = "0.101.7"
|
2023-06-22 10:25:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-06 12:19:55 +00:00
|
|
|
checksum = "8b6275d1ee7a1cd780b64aca7726599a1dbc893b1e64144529e55c3c2f745765"
|
2023-06-22 10:25:30 +00:00
|
|
|
dependencies = [
|
2024-02-25 23:37:15 +00:00
|
|
|
"ring 0.17.8",
|
2023-11-06 12:19:55 +00:00
|
|
|
"untrusted 0.9.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2024-01-17 00:32:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustls-webpki"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.102.7"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "84678086bd54edf2b415183ed7a94d0efb049f1b646a33e22a36f3794be6ae56"
|
2024-01-17 00:32:30 +00:00
|
|
|
dependencies = [
|
2024-02-25 23:37:15 +00:00
|
|
|
"ring 0.17.8",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-pki-types",
|
|
|
|
"untrusted 0.9.0",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rustversion"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.0.17"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "955d28af4278de8121b7ebeb796b6a45735dc01436d898801014aced2773a3d6"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rusty-fork"
|
|
|
|
version = "0.3.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "cb3dcc6e454c328bb824492db107ab7c0ae8fcffe4ad210136ef014458c1bc4f"
|
|
|
|
dependencies = [
|
|
|
|
"fnv",
|
|
|
|
"quick-error",
|
|
|
|
"tempfile",
|
|
|
|
"wait-timeout",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "rw-stream-sink"
|
2023-07-28 03:38:04 +00:00
|
|
|
version = "0.4.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-28 03:38:04 +00:00
|
|
|
checksum = "d8c9026ff5d2f23da5e45bbc283f156383001bfb09c4e44256d02c1a685fe9a1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"pin-project",
|
|
|
|
"static_assertions",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "ryu"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.0.18"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "f3cb5ba0dc43242ce17de99c180e96db90b235b8a9fdc9543c96d2209116bd9f"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2022-07-17 01:06:54 +00:00
|
|
|
[[package]]
|
2023-03-06 12:39:43 +00:00
|
|
|
name = "safe_arch"
|
2024-06-19 16:39:47 +00:00
|
|
|
version = "0.7.2"
|
2022-07-17 01:06:54 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-19 16:39:47 +00:00
|
|
|
checksum = "c3460605018fdc9612bce72735cba0d27efbcd9904780d44c7e3a9948f96148a"
|
2022-07-17 01:06:54 +00:00
|
|
|
dependencies = [
|
2023-03-06 12:39:43 +00:00
|
|
|
"bytemuck",
|
2022-07-17 01:06:54 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "same-file"
|
|
|
|
version = "1.0.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "93fc1dc3aaa9bfed95e02e6eadabb4baf7e3078b0bd1b4d7b6b0b68378900502"
|
|
|
|
dependencies = [
|
|
|
|
"winapi-util",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-allocator"
|
|
|
|
version = "4.1.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"log",
|
|
|
|
"sp-core",
|
|
|
|
"sp-wasm-interface",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-authority-discovery"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"ip_network",
|
|
|
|
"libp2p",
|
|
|
|
"log",
|
2023-07-28 03:38:04 +00:00
|
|
|
"multihash-codetable",
|
2023-03-26 12:43:01 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"prost",
|
|
|
|
"prost-build",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-network",
|
|
|
|
"sp-api",
|
|
|
|
"sp-authority-discovery",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-runtime",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-basic-authorship"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sc-block-builder",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-proposer-metrics",
|
|
|
|
"sc-telemetry",
|
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-core",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-runtime",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-block-builder"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sc-client-api",
|
|
|
|
"sp-api",
|
|
|
|
"sp-block-builder",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-runtime",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-chain-spec"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-18 19:30:38 +00:00
|
|
|
"memmap2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-chain-spec-derive",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-executor",
|
|
|
|
"sc-network",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-telemetry",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-blockchain",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-state-machine",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-chain-spec-derive"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-cli"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"array-bytes",
|
2022-07-16 21:49:35 +00:00
|
|
|
"chrono",
|
2023-06-22 10:25:30 +00:00
|
|
|
"clap",
|
2022-07-16 21:49:35 +00:00
|
|
|
"fdlimit",
|
|
|
|
"futures",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"names",
|
|
|
|
"parity-scale-codec",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"regex",
|
|
|
|
"rpassword",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-client-db",
|
|
|
|
"sc-keystore",
|
|
|
|
"sc-network",
|
|
|
|
"sc-service",
|
|
|
|
"sc-telemetry",
|
|
|
|
"sc-tracing",
|
|
|
|
"sc-utils",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-keyring",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-panic-handler",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-version",
|
|
|
|
"thiserror",
|
|
|
|
"tiny-bip39",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-client-api"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-executor",
|
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"sc-utils",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-core",
|
|
|
|
"sp-database",
|
|
|
|
"sp-externalities",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-state-machine",
|
|
|
|
"sp-storage",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-client-db"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"hash-db",
|
|
|
|
"kvdb",
|
|
|
|
"kvdb-memorydb",
|
|
|
|
"kvdb-rocksdb",
|
|
|
|
"linked-hash-map",
|
|
|
|
"log",
|
|
|
|
"parity-db",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-state-db",
|
2023-03-06 12:39:43 +00:00
|
|
|
"schnellru",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-arithmetic",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-database",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-state-machine",
|
|
|
|
"sp-trie",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-consensus"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-01-04 08:17:36 +00:00
|
|
|
"mockall",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-utils",
|
|
|
|
"serde",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-state-machine",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-consensus-babe"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"fork-tree",
|
|
|
|
"futures",
|
|
|
|
"log",
|
|
|
|
"num-bigint",
|
|
|
|
"num-rational",
|
|
|
|
"num-traits",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-consensus",
|
|
|
|
"sc-consensus-epochs",
|
|
|
|
"sc-consensus-slots",
|
|
|
|
"sc-telemetry",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sc-transaction-pool-api",
|
2023-03-26 12:43:01 +00:00
|
|
|
"scale-info",
|
|
|
|
"sp-api",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-block-builder",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-consensus-babe",
|
|
|
|
"sp-consensus-slots",
|
|
|
|
"sp-core",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-runtime",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-consensus-epochs"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"fork-tree",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-consensus",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-runtime",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-consensus-grandpa"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
2023-08-22 02:58:45 +00:00
|
|
|
"ahash",
|
2023-03-26 12:43:01 +00:00
|
|
|
"array-bytes",
|
|
|
|
"async-trait",
|
|
|
|
"dyn-clone",
|
|
|
|
"finality-grandpa",
|
|
|
|
"fork-tree",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-block-builder",
|
|
|
|
"sc-chain-spec",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-consensus",
|
|
|
|
"sc-network",
|
|
|
|
"sc-network-common",
|
|
|
|
"sc-network-gossip",
|
|
|
|
"sc-telemetry",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sc-transaction-pool-api",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-utils",
|
|
|
|
"serde_json",
|
|
|
|
"sp-api",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-arithmetic",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-consensus-grandpa",
|
|
|
|
"sp-core",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-runtime",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-consensus-slots"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-consensus",
|
|
|
|
"sc-telemetry",
|
|
|
|
"sp-arithmetic",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-consensus-slots",
|
|
|
|
"sp-core",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-state-machine",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-executor"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-executor-common",
|
|
|
|
"sc-executor-wasmtime",
|
2023-07-19 02:30:55 +00:00
|
|
|
"schnellru",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-api",
|
|
|
|
"sp-core",
|
|
|
|
"sp-externalities",
|
|
|
|
"sp-io",
|
|
|
|
"sp-panic-handler",
|
|
|
|
"sp-runtime-interface",
|
|
|
|
"sp-trie",
|
|
|
|
"sp-version",
|
|
|
|
"sp-wasm-interface",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-executor-common"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"sc-allocator",
|
|
|
|
"sp-maybe-compressed-blob",
|
|
|
|
"sp-wasm-interface",
|
|
|
|
"thiserror",
|
|
|
|
"wasm-instrument",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-executor-wasmtime"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-03-06 12:39:43 +00:00
|
|
|
"anyhow",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cfg-if",
|
|
|
|
"libc",
|
|
|
|
"log",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-allocator",
|
|
|
|
"sc-executor-common",
|
|
|
|
"sp-runtime-interface",
|
|
|
|
"sp-wasm-interface",
|
|
|
|
"wasmtime",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-informant"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-04-15 07:27:45 +00:00
|
|
|
"anstyle",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"log",
|
|
|
|
"sc-client-api",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sc-network-common",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-blockchain",
|
|
|
|
"sp-runtime",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-keystore"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"array-bytes",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde_json",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-core",
|
|
|
|
"sp-keystore",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-network"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"array-bytes",
|
2023-03-26 12:43:01 +00:00
|
|
|
"async-channel",
|
2022-07-16 21:49:35 +00:00
|
|
|
"async-trait",
|
|
|
|
"asynchronous-codec",
|
|
|
|
"bytes",
|
|
|
|
"either",
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"ip_network",
|
|
|
|
"libp2p",
|
2023-03-26 12:43:01 +00:00
|
|
|
"linked_hash_set",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-03-06 12:39:43 +00:00
|
|
|
"mockall",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-07-19 02:30:55 +00:00
|
|
|
"partial_sort",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pin-project",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-network-common",
|
|
|
|
"sc-utils",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sp-arithmetic",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"thiserror",
|
|
|
|
"unsigned-varint",
|
2023-07-28 03:38:04 +00:00
|
|
|
"void",
|
2023-07-19 02:30:55 +00:00
|
|
|
"wasm-timer",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-network-bitswap"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"async-channel",
|
2022-09-29 18:33:09 +00:00
|
|
|
"cid",
|
|
|
|
"futures",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-identity",
|
2022-09-29 18:33:09 +00:00
|
|
|
"log",
|
2022-10-20 05:05:36 +00:00
|
|
|
"prost",
|
|
|
|
"prost-build",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sc-client-api",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-blockchain",
|
|
|
|
"sp-runtime",
|
|
|
|
"thiserror",
|
|
|
|
"unsigned-varint",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-network-common"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"async-trait",
|
2023-06-28 18:57:58 +00:00
|
|
|
"bitflags 1.3.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
2022-10-20 05:05:36 +00:00
|
|
|
"prost-build",
|
2022-08-16 07:44:32 +00:00
|
|
|
"sc-consensus",
|
|
|
|
"sp-consensus",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-consensus-grandpa",
|
2022-08-16 07:44:32 +00:00
|
|
|
"sp-runtime",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-network-gossip"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
dependencies = [
|
2023-08-22 02:58:45 +00:00
|
|
|
"ahash",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
2023-07-28 03:38:04 +00:00
|
|
|
"libp2p-identity",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"log",
|
2023-07-28 03:38:04 +00:00
|
|
|
"multiaddr",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"sc-network-common",
|
2023-07-19 02:30:55 +00:00
|
|
|
"schnellru",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"sp-runtime",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-network-light"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"array-bytes",
|
2023-06-28 18:57:58 +00:00
|
|
|
"async-channel",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
2023-06-28 18:57:58 +00:00
|
|
|
"libp2p-identity",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2022-10-20 05:05:36 +00:00
|
|
|
"prost",
|
|
|
|
"prost-build",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-client-api",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-network-sync"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"array-bytes",
|
2023-06-28 18:57:58 +00:00
|
|
|
"async-channel",
|
2023-01-04 08:17:36 +00:00
|
|
|
"async-trait",
|
2022-07-16 21:49:35 +00:00
|
|
|
"fork-tree",
|
|
|
|
"futures",
|
2023-03-26 12:43:01 +00:00
|
|
|
"futures-timer",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libp2p",
|
|
|
|
"log",
|
2022-10-20 05:05:36 +00:00
|
|
|
"mockall",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
2022-10-20 05:05:36 +00:00
|
|
|
"prost",
|
|
|
|
"prost-build",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-consensus",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-network-common",
|
2022-10-20 05:05:36 +00:00
|
|
|
"sc-utils",
|
2023-07-19 02:30:55 +00:00
|
|
|
"schnellru",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-arithmetic",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-consensus-grandpa",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
2023-01-04 08:17:36 +00:00
|
|
|
"substrate-prometheus-endpoint",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-network-transactions"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
|
|
|
"array-bytes",
|
|
|
|
"futures",
|
|
|
|
"libp2p",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sc-network-common",
|
2023-01-16 15:42:31 +00:00
|
|
|
"sc-utils",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-consensus",
|
|
|
|
"sp-runtime",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-offchain"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"fnv",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
2024-07-15 00:27:36 +00:00
|
|
|
"hyper 0.14.30",
|
2022-09-29 18:33:09 +00:00
|
|
|
"libp2p",
|
2023-07-19 02:30:55 +00:00
|
|
|
"log",
|
2022-07-16 21:49:35 +00:00
|
|
|
"num_cpus",
|
|
|
|
"once_cell",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-client-api",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sc-transaction-pool-api",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-utils",
|
|
|
|
"sp-api",
|
|
|
|
"sp-core",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sp-externalities",
|
|
|
|
"sp-keystore",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-offchain",
|
|
|
|
"sp-runtime",
|
|
|
|
"threadpool",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-proposer-metrics"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"log",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-rpc"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"jsonrpsee",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-block-builder",
|
|
|
|
"sc-chain-spec",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-rpc-api",
|
|
|
|
"sc-tracing",
|
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"sc-utils",
|
|
|
|
"serde_json",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-offchain",
|
|
|
|
"sp-rpc",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-session",
|
|
|
|
"sp-version",
|
2023-03-06 12:39:43 +00:00
|
|
|
"tokio",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-rpc-api"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"jsonrpsee",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sc-chain-spec",
|
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"sp-core",
|
|
|
|
"sp-rpc",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-version",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-rpc-server"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2022-07-16 21:49:35 +00:00
|
|
|
"jsonrpsee",
|
|
|
|
"log",
|
|
|
|
"serde_json",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"tokio",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tower",
|
|
|
|
"tower-http",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-rpc-spec-v2"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-10-20 05:05:36 +00:00
|
|
|
dependencies = [
|
2023-01-16 15:42:31 +00:00
|
|
|
"array-bytes",
|
2022-10-20 05:05:36 +00:00
|
|
|
"futures",
|
2023-01-16 15:42:31 +00:00
|
|
|
"futures-util",
|
2022-10-20 05:05:36 +00:00
|
|
|
"hex",
|
|
|
|
"jsonrpsee",
|
2023-01-16 15:42:31 +00:00
|
|
|
"log",
|
2022-10-20 05:05:36 +00:00
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-10-20 05:05:36 +00:00
|
|
|
"sc-chain-spec",
|
2023-01-16 15:42:31 +00:00
|
|
|
"sc-client-api",
|
2022-10-20 05:05:36 +00:00
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"serde",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
2023-01-16 15:42:31 +00:00
|
|
|
"sp-version",
|
2022-10-20 05:05:36 +00:00
|
|
|
"thiserror",
|
2023-01-16 15:42:31 +00:00
|
|
|
"tokio-stream",
|
2022-10-20 05:05:36 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sc-service"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"directories",
|
|
|
|
"exit-future",
|
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"jsonrpsee",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pin-project",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-block-builder",
|
|
|
|
"sc-chain-spec",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-client-db",
|
|
|
|
"sc-consensus",
|
|
|
|
"sc-executor",
|
|
|
|
"sc-informant",
|
|
|
|
"sc-keystore",
|
|
|
|
"sc-network",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sc-network-bitswap",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-network-common",
|
2022-08-16 07:44:32 +00:00
|
|
|
"sc-network-light",
|
|
|
|
"sc-network-sync",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sc-network-transactions",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-rpc",
|
|
|
|
"sc-rpc-server",
|
2022-10-20 05:05:36 +00:00
|
|
|
"sc-rpc-spec-v2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-sysinfo",
|
|
|
|
"sc-telemetry",
|
|
|
|
"sc-tracing",
|
|
|
|
"sc-transaction-pool",
|
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"sc-utils",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-core",
|
|
|
|
"sp-externalities",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-session",
|
|
|
|
"sp-state-machine",
|
|
|
|
"sp-storage",
|
|
|
|
"sp-transaction-pool",
|
|
|
|
"sp-trie",
|
|
|
|
"sp-version",
|
2022-09-29 18:33:09 +00:00
|
|
|
"static_init",
|
2022-07-16 21:49:35 +00:00
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"tempfile",
|
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
"tracing",
|
|
|
|
"tracing-futures",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-state-db"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-sysinfo"
|
|
|
|
version = "6.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"libc",
|
|
|
|
"log",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-01-16 15:42:31 +00:00
|
|
|
"rand_pcg",
|
2022-07-16 21:49:35 +00:00
|
|
|
"regex",
|
|
|
|
"sc-telemetry",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-telemetry"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"chrono",
|
|
|
|
"futures",
|
|
|
|
"libp2p",
|
|
|
|
"log",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pin-project",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-01-16 15:42:31 +00:00
|
|
|
"sc-utils",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"thiserror",
|
|
|
|
"wasm-timer",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-tracing"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-04-15 07:27:45 +00:00
|
|
|
"anstyle",
|
2022-07-16 21:49:35 +00:00
|
|
|
"chrono",
|
|
|
|
"lazy_static",
|
|
|
|
"libc",
|
|
|
|
"log",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"regex",
|
|
|
|
"rustc-hash",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-tracing-proc-macro",
|
|
|
|
"serde",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-rpc",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-tracing",
|
|
|
|
"thiserror",
|
|
|
|
"tracing",
|
|
|
|
"tracing-log",
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
"tracing-subscriber 0.2.25",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-tracing-proc-macro"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-transaction-pool"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-10-20 05:05:36 +00:00
|
|
|
"async-trait",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"linked-hash-map",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-client-api",
|
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"sc-utils",
|
|
|
|
"serde",
|
|
|
|
"sp-api",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-tracing",
|
|
|
|
"sp-transaction-pool",
|
|
|
|
"substrate-prometheus-endpoint",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-transaction-pool-api"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-10-20 05:05:36 +00:00
|
|
|
"async-trait",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
|
|
|
"log",
|
2023-07-19 02:30:55 +00:00
|
|
|
"parity-scale-codec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
|
|
|
"sp-blockchain",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sp-core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-runtime",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sc-utils"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-03-26 12:43:01 +00:00
|
|
|
"async-channel",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
|
|
|
"futures-timer",
|
|
|
|
"lazy_static",
|
|
|
|
"log",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"prometheus",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-arithmetic",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "scale-info"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "2.11.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "eca070c12893629e2cc820a9761bedf6ce1dcddc9852984d1dc734b8bd9bd024"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-08-23 17:24:21 +00:00
|
|
|
"bitvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cfg-if",
|
2024-09-05 21:03:23 +00:00
|
|
|
"derive_more 0.99.18",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info-derive",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "scale-info-derive"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "2.11.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "2d35494501194174bda522a32605929eefc9ecf7e0a326c26db1fdd85881eb62"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"proc-macro-crate 3.2.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "schannel"
|
2023-12-30 07:36:51 +00:00
|
|
|
version = "0.1.23"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-30 07:36:51 +00:00
|
|
|
checksum = "fbc91545643bcf3a0bbb6569265615222618bdf33ce4ffbbd13c4bbd4c093534"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-12-30 07:36:51 +00:00
|
|
|
"windows-sys 0.52.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "schnellru"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.2.3"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "c9a8ef13a93c54d20580de1e5c413e624e53121d42fc7e2c11d10ef7f8b02367"
|
2023-03-06 12:39:43 +00:00
|
|
|
dependencies = [
|
2023-08-22 02:58:45 +00:00
|
|
|
"ahash",
|
2023-03-06 12:39:43 +00:00
|
|
|
"cfg-if",
|
|
|
|
"hashbrown 0.13.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-10-29 08:54:42 +00:00
|
|
|
[[package]]
|
|
|
|
name = "schnorr-signatures"
|
2023-08-08 22:30:19 +00:00
|
|
|
version = "0.5.1"
|
2022-10-29 08:54:42 +00:00
|
|
|
dependencies = [
|
|
|
|
"ciphersuite",
|
|
|
|
"dalek-ff-group",
|
2023-03-02 15:04:18 +00:00
|
|
|
"flexible-transcript",
|
|
|
|
"hex",
|
2022-10-29 08:54:42 +00:00
|
|
|
"multiexp",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-04-22 08:38:47 +00:00
|
|
|
"std-shims",
|
2022-10-29 08:54:42 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-08-17 05:25:50 +00:00
|
|
|
[[package]]
|
|
|
|
name = "schnorrkel"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.11.4"
|
2023-09-12 12:42:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "8de18f6d8ba0aad7045f5feae07ec29899c1112584a38509a84ad7b04451eaa0"
|
2023-08-17 05:25:50 +00:00
|
|
|
dependencies = [
|
2024-05-21 12:07:32 +00:00
|
|
|
"aead",
|
2023-08-17 05:25:50 +00:00
|
|
|
"arrayref",
|
|
|
|
"arrayvec",
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2024-05-21 12:07:32 +00:00
|
|
|
"getrandom_or_panic",
|
2023-08-17 05:25:50 +00:00
|
|
|
"merlin",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-08-17 05:25:50 +00:00
|
|
|
"serde_bytes",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-08-17 05:25:50 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "scoped-tls"
|
|
|
|
version = "1.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e1cf6437eb19a8f4a6cc0f7dca544973b0b78843adbfeb3683d1a94a0024a294"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "scopeguard"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "1.2.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "94143f37725109f92c262ed2cf5e59bce7498c01bcc1502d7b9afe439a4e9f49"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "scratch"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "1.0.7"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "a3cf7c11c38cb994f3d40e8a8cde3bbd1f72a435e4c49e85d6553d8312306152"
|
2022-10-20 05:05:36 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sct"
|
2023-11-06 12:19:55 +00:00
|
|
|
version = "0.7.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-06 12:19:55 +00:00
|
|
|
checksum = "da046153aa2352493d6cb7da4b6e5c0c057d8a1d0a9aa8560baffdd945acd414"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-02-25 23:37:15 +00:00
|
|
|
"ring 0.17.8",
|
2023-11-06 12:19:55 +00:00
|
|
|
"untrusted 0.9.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sec1"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "0.7.3"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-19 02:30:55 +00:00
|
|
|
checksum = "d3e97a565f76233a6003f9f5c54be1d9c5bdfa3eccfb189469f11ec4901c47dc"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"base16ct",
|
|
|
|
"der",
|
2023-10-29 13:07:14 +00:00
|
|
|
"generic-array 0.14.7",
|
2023-07-28 03:38:04 +00:00
|
|
|
"pkcs8",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "secp256k1"
|
2024-05-21 09:27:01 +00:00
|
|
|
version = "0.29.0"
|
2022-07-17 21:17:23 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 09:27:01 +00:00
|
|
|
checksum = "0e0cc0f1cf93f4969faf3ea1c7d8a9faed25918d96affa959720823dfe86d4f3"
|
2022-07-17 21:17:23 +00:00
|
|
|
dependencies = [
|
2023-01-31 12:48:14 +00:00
|
|
|
"bitcoin_hashes",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-08-16 07:44:32 +00:00
|
|
|
"secp256k1-sys",
|
2023-01-31 12:48:14 +00:00
|
|
|
"serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "secp256k1-sys"
|
2024-05-21 09:27:01 +00:00
|
|
|
version = "0.10.0"
|
2022-07-17 21:17:23 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 09:27:01 +00:00
|
|
|
checksum = "1433bd67156263443f14d603720b082dd3121779323fce20cba2aa07b874bc1b"
|
2022-07-17 21:17:23 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
]
|
|
|
|
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
[[package]]
|
|
|
|
name = "secq256k1"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"blake2",
|
|
|
|
"ciphersuite",
|
|
|
|
"crypto-bigint",
|
|
|
|
"ec-divisors",
|
|
|
|
"ff-group-tests",
|
|
|
|
"generalized-bulletproofs-ec-gadgets",
|
|
|
|
"generic-array 0.14.7",
|
|
|
|
"hex",
|
|
|
|
"hex-literal",
|
|
|
|
"k256",
|
|
|
|
"rand_core",
|
|
|
|
"rustversion",
|
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "secrecy"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9bd1c54ea06cfd2f6b63219704de0b9b4f72dcc2b8fdef820be6cd799780e91e"
|
|
|
|
dependencies = [
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "security-framework"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "2.11.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "897b2245f0b511c87893af39b033e5ca9cce68824c4d7e7630b5a1d339658d02"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"core-foundation",
|
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
|
|
|
"security-framework-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "security-framework-sys"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "2.11.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "75da29fe9b9b08fe9d6b22b5b4bcbc75d8db3aa31e639aa56bb62e9d46bfceaf"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "semver"
|
|
|
|
version = "0.6.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7a3186ec9e65071a2095434b1f5bb24838d4e8e130f584c790f6033c79943537"
|
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"semver-parser 0.7.0",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "semver"
|
|
|
|
version = "0.11.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f301af10236f6df4160f7c3f04eec6dbc70ace82d23326abad5edee88801c6b6"
|
|
|
|
dependencies = [
|
|
|
|
"semver-parser 0.10.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "semver"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.0.23"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "61697e0a1c7e512e84a621326239844a24d8207b4669b41bc18b32ea5cbf988b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "semver-parser"
|
|
|
|
version = "0.7.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "388a1df253eca08550bef6c72392cfe7c30914bf41df5269b68cbd6ff8f570a3"
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
name = "semver-parser"
|
|
|
|
version = "0.10.2"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
checksum = "00b0bef5b7f9e0df16536d3961cfb6e84331c065b4066afb39768d0e319411f7"
|
|
|
|
dependencies = [
|
|
|
|
"pest",
|
|
|
|
]
|
2023-03-25 04:45:33 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "send_wrapper"
|
2023-03-06 12:39:43 +00:00
|
|
|
version = "0.6.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-06 12:39:43 +00:00
|
|
|
checksum = "cd0b0ec5f1c1ca621c432a25813d8d60c88abe6d3e08a3eb9cf37d97a0fe3d73"
|
2022-07-18 00:56:10 +00:00
|
|
|
|
2023-12-06 14:53:48 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-abi"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"bitvec",
|
2023-12-06 14:53:48 +00:00
|
|
|
"borsh",
|
|
|
|
"frame-support",
|
|
|
|
"parity-scale-codec",
|
2023-12-07 07:30:09 +00:00
|
|
|
"scale-info",
|
2023-12-06 14:53:48 +00:00
|
|
|
"serai-coins-primitives",
|
2024-08-15 03:12:04 +00:00
|
|
|
"serai-emissions-primitives",
|
2024-07-18 23:30:19 +00:00
|
|
|
"serai-genesis-liquidity-primitives",
|
2023-12-06 14:53:48 +00:00
|
|
|
"serai-in-instructions-primitives",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-signals-primitives",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
"serde",
|
|
|
|
"sp-consensus-babe",
|
|
|
|
"sp-consensus-grandpa",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
]
|
|
|
|
|
2024-09-06 07:20:38 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-bitcoin-processor"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"bitcoin-serai",
|
|
|
|
"borsh",
|
2024-09-10 07:48:06 +00:00
|
|
|
"ciphersuite",
|
2024-09-11 07:23:00 +00:00
|
|
|
"dkg",
|
2024-09-10 07:48:06 +00:00
|
|
|
"flexible-transcript",
|
2024-09-11 22:56:23 +00:00
|
|
|
"hex",
|
2024-09-06 07:20:38 +00:00
|
|
|
"log",
|
2024-09-10 07:48:06 +00:00
|
|
|
"modular-frost",
|
2024-09-06 07:20:38 +00:00
|
|
|
"parity-scale-codec",
|
2024-09-10 07:48:06 +00:00
|
|
|
"rand_core",
|
2024-09-06 07:20:38 +00:00
|
|
|
"secp256k1",
|
2024-09-10 07:48:06 +00:00
|
|
|
"serai-client",
|
2024-09-06 07:20:38 +00:00
|
|
|
"serai-db",
|
2024-09-11 22:56:23 +00:00
|
|
|
"serai-processor-bin",
|
2024-09-11 07:23:00 +00:00
|
|
|
"serai-processor-key-gen",
|
2024-09-10 07:48:06 +00:00
|
|
|
"serai-processor-primitives",
|
2024-09-10 11:07:09 +00:00
|
|
|
"serai-processor-scanner",
|
2024-09-10 07:48:06 +00:00
|
|
|
"serai-processor-scheduler-primitives",
|
2024-09-11 04:48:52 +00:00
|
|
|
"serai-processor-signers",
|
2024-09-11 04:01:40 +00:00
|
|
|
"serai-processor-transaction-chaining-scheduler",
|
|
|
|
"serai-processor-utxo-scheduler-primitives",
|
2024-09-06 07:20:38 +00:00
|
|
|
"tokio",
|
|
|
|
"zalloc",
|
|
|
|
]
|
|
|
|
|
2022-07-18 00:56:10 +00:00
|
|
|
[[package]]
|
2023-01-20 16:00:18 +00:00
|
|
|
name = "serai-client"
|
2022-07-18 00:56:10 +00:00
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-12-08 13:41:14 +00:00
|
|
|
"async-lock",
|
Processor (#259)
* Initial work on a message box
* Finish message-box (untested)
* Expand documentation
* Embed the recipient in the signature challenge
Prevents a message from A -> B from being read as from A -> C.
* Update documentation by bifurcating sender/receiver
* Panic on receiving an invalid signature
If we've received an invalid signature in an authenticated system, a
service is malicious, critically faulty (equivalent to malicious), or
the message layer has been compromised (or is otherwise critically
faulty).
Please note a receiver who handles a message they shouldn't will trigger
this. That falls under being critically faulty.
* Documentation and helper methods
SecureMessage::new and SecureMessage::serialize.
Secure Debug for MessageBox.
* Have SecureMessage not be serialized by default
Allows passing around in-memory, if desired, and moves the error from
decrypt to new (which performs deserialization).
Decrypt no longer has an error since it panics if given an invalid
signature, due to this being intranet code.
* Explain and improve nonce handling
Includes a missing zeroize call.
* Rebase to latest develop
Updates to transcript 0.2.0.
* Add a test for the MessageBox
* Export PrivateKey and PublicKey
* Also test serialization
* Add a key_gen binary to message_box
* Have SecureMessage support Serde
* Add encrypt_to_bytes and decrypt_from_bytes
* Support String ser via base64
* Rename encrypt/decrypt to encrypt_bytes/decrypt_to_bytes
* Directly operate with values supporting Borsh
* Use bincode instead of Borsh
By staying inside of serde, we'll support many more structs. While
bincode isn't canonical, we don't need canonicity on an authenticated,
internal system.
* Turn PrivateKey, PublicKey into structs
Uses Zeroizing for the PrivateKey per #150.
* from_string functions intended for loading from an env
* Use &str for PublicKey from_string (now from_str)
The PrivateKey takes the String to take ownership of its memory and
zeroize it. That isn't needed with PublicKeys.
* Finish updating from develop
* Resolve warning
* Use ZeroizingAlloc on the key_gen binary
* Move message-box from crypto/ to common/
* Move key serialization functions to ser
* add/remove functions in MessageBox
* Implement Hash on dalek_ff_group Points
* Make MessageBox generic to its key
Exposes a &'static str variant for internal use and a RistrettoPoint
variant for external use.
* Add Private to_string as deprecated
Stub before more competent tooling is deployed.
* Private to_public
* Test both Internal and External MessageBox, only use PublicKey in the pub API
* Remove panics on invalid signatures
Leftover from when this was solely internal which is now unsafe.
* Chicken scratch a Scanner task
* Add a write function to the DKG library
Enables writing directly to a file.
Also modifies serialize to return Zeroizing<Vec<u8>> instead of just Vec<u8>.
* Make dkg::encryption pub
* Remove encryption from MessageBox
* Use a 64-bit block number in Substrate
We use a 64-bit block number in general since u32 only works for 120 years
(with a 1 second block time). As some chains even push the 1 second threshold,
especially ones based on DAG consensus, this becomes potentially as low as 60
years.
While that should still be plenty, it's not worth wondering/debating. Since
Serai uses 64-bit block numbers elsewhere, this ensures consistency.
* Misc crypto lints
* Get the scanner scratch to compile
* Initial scanner test
* First few lines of scheduler
* Further work on scheduler, solidify API
* Define Scheduler TX format
* Branch creation algorithm
* Document when the branch algorithm isn't perfect
* Only scanned confirmed blocks
* Document Coin
* Remove Canonical/ChainNumber from processor
The processor should be abstracted from canonical numbers thanks to the
coordinator, making this unnecessary.
* Add README documenting processor flow
* Use Zeroize on substrate primitives
* Define messages from/to the processor
* Correct over-specified versioning
* Correct build re: in_instructions::primitives
* Debug/some serde in crypto/
* Use a struct for ValidatorSetInstance
* Add a processor key_gen task
Redos DB handling code.
* Replace trait + impl with wrapper struct
* Add a key confirmation flow to the key gen task
* Document concerns on key_gen
* Start on a signer task
* Add Send to FROST traits
* Move processor lib.rs to main.rs
Adds a dummy main to reduce clippy dead_code warnings.
* Further flesh out main.rs
* Move the DB trait to AsRef<[u8]>
* Signer task
* Remove a panic in bitcoin when there's insufficient funds
Unchecked underflow.
* Have Monero's mine_block mine one block, not 10
It was initially a nicety to deal with the 10 block lock. C::CONFIRMATIONS
should be used for that instead.
* Test signer
* Replace channel expects with log statements
The expects weren't problematic and had nicer code. They just clutter test
output.
* Remove the old wallet file
It predates the coordinator design and shouldn't be used.
* Rename tests/scan.rs to tests/scanner.rs
* Add a wallet test
Complements the recently removed wallet file by adding a test for the scanner,
scheduler, and signer together.
* Work on a run function
Triggers a clippy ICE.
* Resolve clippy ICE
The issue was the non-fully specified lambda in signer.
* Add KeyGenEvent and KeyGenOrder
Needed so we get KeyConfirmed messages from the key gen task.
While we could've read the CoordinatorMessage to see that, routing through the
key gen tasks ensures we only handle it once it's been successfully saved to
disk.
* Expand scanner test
* Clarify processor documentation
* Have the Scanner load keys on boot/save outputs to disk
* Use Vec<u8> for Block ID
Much more flexible.
* Panic if we see the same output multiple times
* Have the Scanner DB mark itself as corrupt when doing a multi-put
This REALLY should be a TX. Since we don't have a TX API right now, this at
least offers detection.
* Have DST'd DB keys accept AsRef<[u8]>
* Restore polling all signers
Writes a custom future to do so.
Also loads signers on boot using what the scanner claims are active keys.
* Schedule OutInstructions
Adds a data field to Payment.
Also cleans some dead code.
* Panic if we create an invalid transaction
Saves the TX once it's successfully signed so if we do panic, we have a copy.
* Route coordinator messages to their respective signer
Requires adding key to the SignId.
* Send SignTransaction orders for all plans
* Add a timer to retry sign_plans when prepare_send fails
* Minor fmt'ing
* Basic Fee API
* Move the change key into Plan
* Properly route activation_number
* Remove ScannerEvent::Block
It's not used under current designs
* Nicen logs
* Add utilities to get a block's number
* Have main issue AckBlock
Also has a few misc lints.
* Parse instructions out of outputs
* Tweak TODOs and remove an unwrap
* Update Bitcoin max input/output quantity
* Only read one piece of data from Monero
Due to output randomization, it's infeasible.
* Embed plan IDs into the TXs they create
We need to stop attempting signing if we've already signed a protocol. Ideally,
any one of the participating signers should be able to provide a proof the TX
was successfully signed. We can't just run a second signing protocol though as
a single malicious signer could complete the TX signature, and publish it,
yet not complete the secondary signature.
The TX itself has to be sufficient to show that the TX matches the plan. This
is done by embedding the ID, so matching addresses/amounts plans are
distinguished, and by allowing verification a TX actually matches a set of
addresses/amounts.
For Monero, this will need augmenting with the ephemeral keys (or usage of a
static seed for them).
* Don't use OP_RETURN to encode the plan ID on Bitcoin
We can use the inputs to distinguih identical-output plans without issue.
* Update OP_RETURN data access
It's not required to be the last output.
* Add Eventualities to Monero
An Eventuality is an effective equivalent to a SignableTransaction. That is
declared not by the inputs it spends, yet the outputs it creates.
Eventualities are also bound to a 32-byte RNG seed, enabling usage of a
hash-based identifier in a SignableTransaction, allowing multiple
SignableTransactions with the same output set to have different Eventualities.
In order to prevent triggering the burning bug, the RNG seed is hashed with
the planned-to-be-used inputs' output keys. While this does bind to them, it's
only loosely bound. The TX actually created may use different inputs entirely
if a forgery is crafted (which requires no brute forcing).
Binding to the key images would provide a strong binding, yet would require
knowing the key images, which requires active communication with the spend
key.
The purpose of this is so a multisig can identify if a Transaction the entire
group planned has been executed by a subset of the group or not. Once a plan
is created, it can have an Eventuality made. The Eventuality's extra is able
to be inserted into a HashMap, so all new on-chain transactions can be
trivially checked as potential candidates. Once a potential candidate is found,
a check involving ECC ops can be performed.
While this is arguably a DoS vector, the underlying Monero blockchain would
need to be spammed with transactions to trigger it. Accordingly, it becomes
a Monero blockchain DoS vector, when this code is written on the premise
of the Monero blockchain functioning. Accordingly, it is considered handled.
If a forgery does match, it must have created the exact same outputs the
multisig would've. Accordingly, it's argued the multisig shouldn't mind.
This entire suite of code is only necessary due to the lack of outgoing
view keys, yet it's able to avoid an interactive protocol to communicate
key images on every single received output.
While this could be locked to the multisig feature, there's no practical
benefit to doing so.
* Add support for encoding Monero address to instructions
* Move Serai's Monero address encoding into serai-client
serai-client is meant to be a single library enabling using Serai. While it was
originally written as an RPC client for Serai, apps actually using Serai will
primarily be sending transactions on connected networks. Sending those
transactions require proper {In, Out}Instructions, including proper address
encoding.
Not only has address encoding been moved, yet the subxt client is now behind
a feature. coin integrations have their own features, which are on by default.
primitives are always exposed.
* Reorganize file layout a bit, add feature flags to processor
* Tidy up ETH Dockerfile
* Add Bitcoin address encoding
* Move Bitcoin::Address to serai-client's
* Comment where tweaking needs to happen
* Add an API to check if a plan was completed in a specific TX
This allows any participating signer to submit the TX ID to prevent further
signing attempts.
Also performs some API cleanup.
* Minimize FROST dependencies
* Use a seeded RNG for key gen
* Tweak keys from Key gen
* Test proper usage of Branch/Change addresses
Adds a more descriptive error to an error case in decoys, and pads Monero
payments as needed.
* Also test spending the change output
* Add queued_plans to the Scheduler
queued_plans is for payments to be issued when an amount appears, yet the
amount is currently pre-fee. One the output is actually created, the
Scheduler should be notified of the amount it was created with, moving from
queued_plans to plans under the actual amount.
Also tightens debug_asserts to asserts for invariants which may are at risk of
being exclusive to prod.
* Add missing tweak_keys call
* Correct decoy selection height handling
* Add a few log statements to the scheduler
* Simplify test's get_block_number
* Simplify, while making more robust, branch address handling in Scheduler
* Have fees deducted from payments
Corrects Monero's handling of fees when there's no change address.
Adds a DUST variable, as needed due to 1_00_000_000 not being enough to pay
its fee on Monero.
* Add comment to Monero
* Consolidate BTC/XMR prepare_send code
These aren't fully consolidated. We'd need a SignableTransaction trait for
that. This is a lot cleaner though.
* Ban integrated addresses
The reasoning why is accordingly documented.
* Tidy TODOs/dust handling
* Update README TODO
* Use a determinisitic protocol version in Monero
* Test rebuilt KeyGen machines function as expected
* Use a more robust KeyGen entropy system
* Add DB TXNs
Also load entropy from env
* Add a loop for processing messages from substrate
Allows detecting if we're behind, and if so, waiting to handle the message
* Set Monero MAX_INPUTS properly
The previous number was based on an old hard fork. With the ring size having
increased, transactions have since got larger.
* Distinguish TODOs into TODO and TODO2s
TODO2s are for after protonet
* Zeroize secret share repr in ThresholdCore write
* Work on Eventualities
Adds serialization and stops signing when an eventuality is proven.
* Use a more robust DB key schema
* Update to {k, p}256 0.12
* cargo +nightly clippy
* cargo update
* Slight message-box tweaks
* Update to recent Monero merge
* Add a Coordinator trait for communication with coordinator
* Remove KeyGenHandle for just KeyGen
While KeyGen previously accepted instructions over a channel, this breaks the
ack flow needed for coordinator communication. Now, KeyGen is the direct object
with a handle() function for messages.
Thankfully, this ended up being rather trivial for KeyGen as it has no
background tasks.
* Add a handle function to Signer
Enables determining when it's finished handling a CoordinatorMessage and
therefore creating an acknowledgement.
* Save transactions used to complete eventualities
* Use a more intelligent sleep in the signer
* Emit SignedTransaction with the first ID *we can still get from our node*
* Move Substrate message handling into the new coordinator recv loop
* Add handle function to Scanner
* Remove the plans timer
Enables ensuring the ordring on the handling of plans.
* Remove the outputs function which panicked if a precondition wasn't met
The new API only returns outputs upon satisfaction of the precondition.
* Convert SignerOrder::SignTransaction to a function
* Remove the key_gen object from sign_plans
* Refactor out get_fee/prepare_send into dedicated functions
* Save plans being signed to the DB
* Reload transactions being signed on boot
* Stop reloading TXs being signed (and report it to peers)
* Remove message-box from the processor branch
We don't use it here yet.
* cargo +nightly fmt
* Move back common/zalloc
* Update subxt to 0.27
* Zeroize ^1.5, not 1
* Update GitHub workflow
* Remove usage of SignId in completed
2023-03-17 02:59:40 +00:00
|
|
|
"bitcoin",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"bitvec",
|
2023-09-29 07:51:01 +00:00
|
|
|
"blake2",
|
2024-09-10 07:48:06 +00:00
|
|
|
"borsh",
|
Processor (#259)
* Initial work on a message box
* Finish message-box (untested)
* Expand documentation
* Embed the recipient in the signature challenge
Prevents a message from A -> B from being read as from A -> C.
* Update documentation by bifurcating sender/receiver
* Panic on receiving an invalid signature
If we've received an invalid signature in an authenticated system, a
service is malicious, critically faulty (equivalent to malicious), or
the message layer has been compromised (or is otherwise critically
faulty).
Please note a receiver who handles a message they shouldn't will trigger
this. That falls under being critically faulty.
* Documentation and helper methods
SecureMessage::new and SecureMessage::serialize.
Secure Debug for MessageBox.
* Have SecureMessage not be serialized by default
Allows passing around in-memory, if desired, and moves the error from
decrypt to new (which performs deserialization).
Decrypt no longer has an error since it panics if given an invalid
signature, due to this being intranet code.
* Explain and improve nonce handling
Includes a missing zeroize call.
* Rebase to latest develop
Updates to transcript 0.2.0.
* Add a test for the MessageBox
* Export PrivateKey and PublicKey
* Also test serialization
* Add a key_gen binary to message_box
* Have SecureMessage support Serde
* Add encrypt_to_bytes and decrypt_from_bytes
* Support String ser via base64
* Rename encrypt/decrypt to encrypt_bytes/decrypt_to_bytes
* Directly operate with values supporting Borsh
* Use bincode instead of Borsh
By staying inside of serde, we'll support many more structs. While
bincode isn't canonical, we don't need canonicity on an authenticated,
internal system.
* Turn PrivateKey, PublicKey into structs
Uses Zeroizing for the PrivateKey per #150.
* from_string functions intended for loading from an env
* Use &str for PublicKey from_string (now from_str)
The PrivateKey takes the String to take ownership of its memory and
zeroize it. That isn't needed with PublicKeys.
* Finish updating from develop
* Resolve warning
* Use ZeroizingAlloc on the key_gen binary
* Move message-box from crypto/ to common/
* Move key serialization functions to ser
* add/remove functions in MessageBox
* Implement Hash on dalek_ff_group Points
* Make MessageBox generic to its key
Exposes a &'static str variant for internal use and a RistrettoPoint
variant for external use.
* Add Private to_string as deprecated
Stub before more competent tooling is deployed.
* Private to_public
* Test both Internal and External MessageBox, only use PublicKey in the pub API
* Remove panics on invalid signatures
Leftover from when this was solely internal which is now unsafe.
* Chicken scratch a Scanner task
* Add a write function to the DKG library
Enables writing directly to a file.
Also modifies serialize to return Zeroizing<Vec<u8>> instead of just Vec<u8>.
* Make dkg::encryption pub
* Remove encryption from MessageBox
* Use a 64-bit block number in Substrate
We use a 64-bit block number in general since u32 only works for 120 years
(with a 1 second block time). As some chains even push the 1 second threshold,
especially ones based on DAG consensus, this becomes potentially as low as 60
years.
While that should still be plenty, it's not worth wondering/debating. Since
Serai uses 64-bit block numbers elsewhere, this ensures consistency.
* Misc crypto lints
* Get the scanner scratch to compile
* Initial scanner test
* First few lines of scheduler
* Further work on scheduler, solidify API
* Define Scheduler TX format
* Branch creation algorithm
* Document when the branch algorithm isn't perfect
* Only scanned confirmed blocks
* Document Coin
* Remove Canonical/ChainNumber from processor
The processor should be abstracted from canonical numbers thanks to the
coordinator, making this unnecessary.
* Add README documenting processor flow
* Use Zeroize on substrate primitives
* Define messages from/to the processor
* Correct over-specified versioning
* Correct build re: in_instructions::primitives
* Debug/some serde in crypto/
* Use a struct for ValidatorSetInstance
* Add a processor key_gen task
Redos DB handling code.
* Replace trait + impl with wrapper struct
* Add a key confirmation flow to the key gen task
* Document concerns on key_gen
* Start on a signer task
* Add Send to FROST traits
* Move processor lib.rs to main.rs
Adds a dummy main to reduce clippy dead_code warnings.
* Further flesh out main.rs
* Move the DB trait to AsRef<[u8]>
* Signer task
* Remove a panic in bitcoin when there's insufficient funds
Unchecked underflow.
* Have Monero's mine_block mine one block, not 10
It was initially a nicety to deal with the 10 block lock. C::CONFIRMATIONS
should be used for that instead.
* Test signer
* Replace channel expects with log statements
The expects weren't problematic and had nicer code. They just clutter test
output.
* Remove the old wallet file
It predates the coordinator design and shouldn't be used.
* Rename tests/scan.rs to tests/scanner.rs
* Add a wallet test
Complements the recently removed wallet file by adding a test for the scanner,
scheduler, and signer together.
* Work on a run function
Triggers a clippy ICE.
* Resolve clippy ICE
The issue was the non-fully specified lambda in signer.
* Add KeyGenEvent and KeyGenOrder
Needed so we get KeyConfirmed messages from the key gen task.
While we could've read the CoordinatorMessage to see that, routing through the
key gen tasks ensures we only handle it once it's been successfully saved to
disk.
* Expand scanner test
* Clarify processor documentation
* Have the Scanner load keys on boot/save outputs to disk
* Use Vec<u8> for Block ID
Much more flexible.
* Panic if we see the same output multiple times
* Have the Scanner DB mark itself as corrupt when doing a multi-put
This REALLY should be a TX. Since we don't have a TX API right now, this at
least offers detection.
* Have DST'd DB keys accept AsRef<[u8]>
* Restore polling all signers
Writes a custom future to do so.
Also loads signers on boot using what the scanner claims are active keys.
* Schedule OutInstructions
Adds a data field to Payment.
Also cleans some dead code.
* Panic if we create an invalid transaction
Saves the TX once it's successfully signed so if we do panic, we have a copy.
* Route coordinator messages to their respective signer
Requires adding key to the SignId.
* Send SignTransaction orders for all plans
* Add a timer to retry sign_plans when prepare_send fails
* Minor fmt'ing
* Basic Fee API
* Move the change key into Plan
* Properly route activation_number
* Remove ScannerEvent::Block
It's not used under current designs
* Nicen logs
* Add utilities to get a block's number
* Have main issue AckBlock
Also has a few misc lints.
* Parse instructions out of outputs
* Tweak TODOs and remove an unwrap
* Update Bitcoin max input/output quantity
* Only read one piece of data from Monero
Due to output randomization, it's infeasible.
* Embed plan IDs into the TXs they create
We need to stop attempting signing if we've already signed a protocol. Ideally,
any one of the participating signers should be able to provide a proof the TX
was successfully signed. We can't just run a second signing protocol though as
a single malicious signer could complete the TX signature, and publish it,
yet not complete the secondary signature.
The TX itself has to be sufficient to show that the TX matches the plan. This
is done by embedding the ID, so matching addresses/amounts plans are
distinguished, and by allowing verification a TX actually matches a set of
addresses/amounts.
For Monero, this will need augmenting with the ephemeral keys (or usage of a
static seed for them).
* Don't use OP_RETURN to encode the plan ID on Bitcoin
We can use the inputs to distinguih identical-output plans without issue.
* Update OP_RETURN data access
It's not required to be the last output.
* Add Eventualities to Monero
An Eventuality is an effective equivalent to a SignableTransaction. That is
declared not by the inputs it spends, yet the outputs it creates.
Eventualities are also bound to a 32-byte RNG seed, enabling usage of a
hash-based identifier in a SignableTransaction, allowing multiple
SignableTransactions with the same output set to have different Eventualities.
In order to prevent triggering the burning bug, the RNG seed is hashed with
the planned-to-be-used inputs' output keys. While this does bind to them, it's
only loosely bound. The TX actually created may use different inputs entirely
if a forgery is crafted (which requires no brute forcing).
Binding to the key images would provide a strong binding, yet would require
knowing the key images, which requires active communication with the spend
key.
The purpose of this is so a multisig can identify if a Transaction the entire
group planned has been executed by a subset of the group or not. Once a plan
is created, it can have an Eventuality made. The Eventuality's extra is able
to be inserted into a HashMap, so all new on-chain transactions can be
trivially checked as potential candidates. Once a potential candidate is found,
a check involving ECC ops can be performed.
While this is arguably a DoS vector, the underlying Monero blockchain would
need to be spammed with transactions to trigger it. Accordingly, it becomes
a Monero blockchain DoS vector, when this code is written on the premise
of the Monero blockchain functioning. Accordingly, it is considered handled.
If a forgery does match, it must have created the exact same outputs the
multisig would've. Accordingly, it's argued the multisig shouldn't mind.
This entire suite of code is only necessary due to the lack of outgoing
view keys, yet it's able to avoid an interactive protocol to communicate
key images on every single received output.
While this could be locked to the multisig feature, there's no practical
benefit to doing so.
* Add support for encoding Monero address to instructions
* Move Serai's Monero address encoding into serai-client
serai-client is meant to be a single library enabling using Serai. While it was
originally written as an RPC client for Serai, apps actually using Serai will
primarily be sending transactions on connected networks. Sending those
transactions require proper {In, Out}Instructions, including proper address
encoding.
Not only has address encoding been moved, yet the subxt client is now behind
a feature. coin integrations have their own features, which are on by default.
primitives are always exposed.
* Reorganize file layout a bit, add feature flags to processor
* Tidy up ETH Dockerfile
* Add Bitcoin address encoding
* Move Bitcoin::Address to serai-client's
* Comment where tweaking needs to happen
* Add an API to check if a plan was completed in a specific TX
This allows any participating signer to submit the TX ID to prevent further
signing attempts.
Also performs some API cleanup.
* Minimize FROST dependencies
* Use a seeded RNG for key gen
* Tweak keys from Key gen
* Test proper usage of Branch/Change addresses
Adds a more descriptive error to an error case in decoys, and pads Monero
payments as needed.
* Also test spending the change output
* Add queued_plans to the Scheduler
queued_plans is for payments to be issued when an amount appears, yet the
amount is currently pre-fee. One the output is actually created, the
Scheduler should be notified of the amount it was created with, moving from
queued_plans to plans under the actual amount.
Also tightens debug_asserts to asserts for invariants which may are at risk of
being exclusive to prod.
* Add missing tweak_keys call
* Correct decoy selection height handling
* Add a few log statements to the scheduler
* Simplify test's get_block_number
* Simplify, while making more robust, branch address handling in Scheduler
* Have fees deducted from payments
Corrects Monero's handling of fees when there's no change address.
Adds a DUST variable, as needed due to 1_00_000_000 not being enough to pay
its fee on Monero.
* Add comment to Monero
* Consolidate BTC/XMR prepare_send code
These aren't fully consolidated. We'd need a SignableTransaction trait for
that. This is a lot cleaner though.
* Ban integrated addresses
The reasoning why is accordingly documented.
* Tidy TODOs/dust handling
* Update README TODO
* Use a determinisitic protocol version in Monero
* Test rebuilt KeyGen machines function as expected
* Use a more robust KeyGen entropy system
* Add DB TXNs
Also load entropy from env
* Add a loop for processing messages from substrate
Allows detecting if we're behind, and if so, waiting to handle the message
* Set Monero MAX_INPUTS properly
The previous number was based on an old hard fork. With the ring size having
increased, transactions have since got larger.
* Distinguish TODOs into TODO and TODO2s
TODO2s are for after protonet
* Zeroize secret share repr in ThresholdCore write
* Work on Eventualities
Adds serialization and stops signing when an eventuality is proven.
* Use a more robust DB key schema
* Update to {k, p}256 0.12
* cargo +nightly clippy
* cargo update
* Slight message-box tweaks
* Update to recent Monero merge
* Add a Coordinator trait for communication with coordinator
* Remove KeyGenHandle for just KeyGen
While KeyGen previously accepted instructions over a channel, this breaks the
ack flow needed for coordinator communication. Now, KeyGen is the direct object
with a handle() function for messages.
Thankfully, this ended up being rather trivial for KeyGen as it has no
background tasks.
* Add a handle function to Signer
Enables determining when it's finished handling a CoordinatorMessage and
therefore creating an acknowledgement.
* Save transactions used to complete eventualities
* Use a more intelligent sleep in the signer
* Emit SignedTransaction with the first ID *we can still get from our node*
* Move Substrate message handling into the new coordinator recv loop
* Add handle function to Scanner
* Remove the plans timer
Enables ensuring the ordring on the handling of plans.
* Remove the outputs function which panicked if a precondition wasn't met
The new API only returns outputs upon satisfaction of the precondition.
* Convert SignerOrder::SignTransaction to a function
* Remove the key_gen object from sign_plans
* Refactor out get_fee/prepare_send into dedicated functions
* Save plans being signed to the DB
* Reload transactions being signed on boot
* Stop reloading TXs being signed (and report it to peers)
* Remove message-box from the processor branch
We don't use it here yet.
* cargo +nightly fmt
* Move back common/zalloc
* Update subxt to 0.27
* Zeroize ^1.5, not 1
* Update GitHub workflow
* Remove usage of SignId in completed
2023-03-17 02:59:40 +00:00
|
|
|
"ciphersuite",
|
2023-10-23 04:33:38 +00:00
|
|
|
"dockertest",
|
2023-12-07 07:30:09 +00:00
|
|
|
"frame-system",
|
2023-05-13 06:02:47 +00:00
|
|
|
"frost-schnorrkel",
|
2023-10-23 04:33:38 +00:00
|
|
|
"hex",
|
2023-05-13 06:02:47 +00:00
|
|
|
"modular-frost",
|
2024-09-12 22:40:10 +00:00
|
|
|
"monero-address",
|
2023-12-23 02:09:18 +00:00
|
|
|
"multiaddr",
|
2022-07-18 00:56:10 +00:00
|
|
|
"parity-scale-codec",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-12-07 07:30:09 +00:00
|
|
|
"serai-abi",
|
2023-10-23 04:33:38 +00:00
|
|
|
"serai-docker-tests",
|
2023-11-28 07:29:50 +00:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"simple-request",
|
2023-01-28 06:47:13 +00:00
|
|
|
"sp-core",
|
2023-11-25 09:02:47 +00:00
|
|
|
"sp-runtime",
|
2023-01-20 16:00:18 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
2023-05-13 06:02:47 +00:00
|
|
|
"zeroize",
|
2022-07-18 00:56:10 +00:00
|
|
|
]
|
|
|
|
|
2023-10-19 10:22:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-coins-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"pallet-transaction-payment",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-coins-primitives",
|
|
|
|
"serai-primitives",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-std",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-coins-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-10-19 10:22:21 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-primitives",
|
|
|
|
"serde",
|
|
|
|
"sp-runtime",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-07-03 12:09:41 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-coordinator"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"bitvec",
|
2023-07-03 12:09:41 +00:00
|
|
|
"blake2",
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-07-03 12:09:41 +00:00
|
|
|
"ciphersuite",
|
2023-08-01 23:00:48 +00:00
|
|
|
"env_logger",
|
2023-07-03 12:09:41 +00:00
|
|
|
"flexible-transcript",
|
2023-08-14 10:08:55 +00:00
|
|
|
"frost-schnorrkel",
|
2023-12-11 00:32:43 +00:00
|
|
|
"futures-util",
|
2023-07-03 12:09:41 +00:00
|
|
|
"hex",
|
2023-08-08 19:12:47 +00:00
|
|
|
"libp2p",
|
2023-07-03 12:09:41 +00:00
|
|
|
"log",
|
|
|
|
"modular-frost",
|
|
|
|
"parity-scale-codec",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-07-03 12:09:41 +00:00
|
|
|
"schnorr-signatures",
|
|
|
|
"serai-client",
|
|
|
|
"serai-db",
|
2023-07-18 05:53:51 +00:00
|
|
|
"serai-env",
|
|
|
|
"serai-message-queue",
|
2023-07-03 12:09:41 +00:00
|
|
|
"serai-processor-messages",
|
|
|
|
"sp-application-crypto",
|
2023-08-14 10:08:55 +00:00
|
|
|
"sp-runtime",
|
2023-07-03 12:09:41 +00:00
|
|
|
"tokio",
|
|
|
|
"tributary-chain",
|
2024-01-04 06:08:13 +00:00
|
|
|
"zalloc",
|
2023-07-03 12:09:41 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-08-01 23:00:48 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-coordinator-tests"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-12-23 02:09:18 +00:00
|
|
|
"async-trait",
|
2023-09-29 08:35:00 +00:00
|
|
|
"blake2",
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-08-01 23:00:48 +00:00
|
|
|
"ciphersuite",
|
2023-08-06 16:38:44 +00:00
|
|
|
"dkg",
|
2023-08-01 23:00:48 +00:00
|
|
|
"dockertest",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"embedwards25519",
|
2023-08-01 23:00:48 +00:00
|
|
|
"hex",
|
2023-09-29 08:35:00 +00:00
|
|
|
"parity-scale-codec",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-08-25 02:05:37 +00:00
|
|
|
"schnorrkel",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"secq256k1",
|
2023-08-01 23:00:48 +00:00
|
|
|
"serai-client",
|
|
|
|
"serai-docker-tests",
|
|
|
|
"serai-message-queue",
|
|
|
|
"serai-message-queue-tests",
|
|
|
|
"serai-processor-messages",
|
|
|
|
"tokio",
|
2023-08-06 16:38:44 +00:00
|
|
|
"zeroize",
|
2023-08-01 23:00:48 +00:00
|
|
|
]
|
|
|
|
|
2023-04-14 15:41:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-db"
|
|
|
|
version = "0.1.0"
|
2023-07-13 23:09:11 +00:00
|
|
|
dependencies = [
|
2023-11-30 09:22:37 +00:00
|
|
|
"parity-db",
|
2024-03-09 06:58:58 +00:00
|
|
|
"rocksdb 0.21.0",
|
2023-07-13 23:09:11 +00:00
|
|
|
]
|
2023-04-14 15:41:01 +00:00
|
|
|
|
2023-11-05 17:02:34 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-dex-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-benchmarking",
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"parity-scale-codec",
|
2024-02-20 01:50:04 +00:00
|
|
|
"rand_core",
|
2023-11-05 17:02:34 +00:00
|
|
|
"scale-info",
|
|
|
|
"serai-coins-pallet",
|
|
|
|
"serai-primitives",
|
|
|
|
"sp-api",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-std",
|
|
|
|
]
|
|
|
|
|
2023-07-21 18:01:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-docker-tests"
|
|
|
|
version = "0.1.0"
|
2023-07-22 08:04:17 +00:00
|
|
|
dependencies = [
|
|
|
|
"chrono",
|
|
|
|
]
|
2023-07-21 18:01:58 +00:00
|
|
|
|
2024-08-31 22:55:42 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-economic-security-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-coins-pallet",
|
|
|
|
"serai-dex-pallet",
|
|
|
|
"serai-primitives",
|
|
|
|
]
|
|
|
|
|
2024-08-15 03:12:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-emissions-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-coins-pallet",
|
|
|
|
"serai-dex-pallet",
|
2024-08-31 22:55:42 +00:00
|
|
|
"serai-economic-security-pallet",
|
2024-08-15 03:12:04 +00:00
|
|
|
"serai-emissions-primitives",
|
|
|
|
"serai-genesis-liquidity-pallet",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-validator-sets-pallet",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-std",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-emissions-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"serai-primitives",
|
|
|
|
]
|
|
|
|
|
2023-07-17 04:50:46 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-env"
|
|
|
|
version = "0.1.0"
|
|
|
|
|
2024-09-06 07:20:38 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-ethereum-processor"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
2024-09-14 09:20:02 +00:00
|
|
|
"ciphersuite",
|
2024-09-14 11:54:18 +00:00
|
|
|
"const-hex",
|
2024-09-14 09:20:02 +00:00
|
|
|
"dkg",
|
2024-09-06 07:20:38 +00:00
|
|
|
"ethereum-serai",
|
|
|
|
"hex",
|
|
|
|
"k256",
|
|
|
|
"log",
|
2024-09-14 09:20:02 +00:00
|
|
|
"modular-frost",
|
2024-09-06 07:20:38 +00:00
|
|
|
"parity-scale-codec",
|
2024-09-14 09:20:02 +00:00
|
|
|
"rand_core",
|
|
|
|
"serai-client",
|
2024-09-06 07:20:38 +00:00
|
|
|
"serai-db",
|
2024-09-14 11:54:18 +00:00
|
|
|
"serai-env",
|
2024-09-14 09:20:02 +00:00
|
|
|
"serai-processor-bin",
|
|
|
|
"serai-processor-key-gen",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
|
|
|
"serai-processor-scheduler-primitives",
|
|
|
|
"serai-processor-signers",
|
|
|
|
"serai-processor-smart-contract-scheduler",
|
2024-09-06 07:20:38 +00:00
|
|
|
"tokio",
|
|
|
|
"zalloc",
|
|
|
|
]
|
|
|
|
|
2024-05-22 22:50:11 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-ethereum-relayer"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"env_logger",
|
|
|
|
"log",
|
|
|
|
"serai-db",
|
|
|
|
"serai-env",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2023-08-27 22:37:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-full-stack-tests"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-12-23 02:09:18 +00:00
|
|
|
"async-trait",
|
2023-08-27 22:37:12 +00:00
|
|
|
"bitcoin-serai",
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2023-08-27 22:37:12 +00:00
|
|
|
"dockertest",
|
|
|
|
"hex",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"monero-simple-request-rpc",
|
|
|
|
"monero-wallet",
|
2023-08-28 20:18:11 +00:00
|
|
|
"parity-scale-codec",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-08-27 22:37:12 +00:00
|
|
|
"serai-client",
|
|
|
|
"serai-coordinator-tests",
|
2023-12-23 02:09:18 +00:00
|
|
|
"serai-docker-tests",
|
2023-08-27 22:37:12 +00:00
|
|
|
"serai-message-queue-tests",
|
|
|
|
"serai-processor-tests",
|
2023-08-28 20:18:11 +00:00
|
|
|
"serde",
|
|
|
|
"serde_json",
|
2023-08-27 22:37:12 +00:00
|
|
|
"tokio",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2024-07-18 23:30:19 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-genesis-liquidity-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-coins-pallet",
|
|
|
|
"serai-dex-pallet",
|
2024-08-31 22:55:42 +00:00
|
|
|
"serai-economic-security-pallet",
|
2024-07-18 23:30:19 +00:00
|
|
|
"serai-genesis-liquidity-primitives",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-validator-sets-pallet",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-core",
|
|
|
|
"sp-std",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-genesis-liquidity-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
"serde",
|
|
|
|
"sp-std",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-07-03 12:09:41 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-in-instructions-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2023-10-19 10:22:21 +00:00
|
|
|
"serai-coins-pallet",
|
2023-11-05 17:02:34 +00:00
|
|
|
"serai-dex-pallet",
|
2024-08-15 03:12:04 +00:00
|
|
|
"serai-emissions-pallet",
|
2024-07-18 23:30:19 +00:00
|
|
|
"serai-genesis-liquidity-pallet",
|
2023-07-03 12:09:41 +00:00
|
|
|
"serai-in-instructions-primitives",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-validator-sets-pallet",
|
|
|
|
"sp-application-crypto",
|
2023-08-14 15:57:38 +00:00
|
|
|
"sp-core",
|
2023-09-29 07:51:01 +00:00
|
|
|
"sp-io",
|
2023-07-03 12:09:41 +00:00
|
|
|
"sp-runtime",
|
2023-11-05 17:02:34 +00:00
|
|
|
"sp-std",
|
2023-07-03 12:09:41 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-in-instructions-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-07-03 12:09:41 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2023-10-19 10:22:21 +00:00
|
|
|
"serai-coins-primitives",
|
2023-07-03 12:09:41 +00:00
|
|
|
"serai-primitives",
|
|
|
|
"serde",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-07-03 12:09:41 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-07-01 12:53:46 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-message-queue"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-07-01 12:53:46 +00:00
|
|
|
"ciphersuite",
|
2023-07-20 22:53:03 +00:00
|
|
|
"env_logger",
|
2023-07-01 12:53:46 +00:00
|
|
|
"flexible-transcript",
|
|
|
|
"hex",
|
2023-07-20 22:53:03 +00:00
|
|
|
"log",
|
2023-11-05 14:43:40 +00:00
|
|
|
"once_cell",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-07-01 12:53:46 +00:00
|
|
|
"schnorr-signatures",
|
|
|
|
"serai-db",
|
2023-07-17 04:50:46 +00:00
|
|
|
"serai-env",
|
2023-07-01 12:53:46 +00:00
|
|
|
"serai-primitives",
|
|
|
|
"tokio",
|
2024-01-04 06:08:13 +00:00
|
|
|
"zalloc",
|
2023-07-18 05:53:51 +00:00
|
|
|
"zeroize",
|
2023-07-01 12:53:46 +00:00
|
|
|
]
|
|
|
|
|
2023-07-20 22:53:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-message-queue-tests"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ciphersuite",
|
|
|
|
"dockertest",
|
|
|
|
"hex",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-07-21 18:01:58 +00:00
|
|
|
"serai-docker-tests",
|
2023-07-20 22:53:03 +00:00
|
|
|
"serai-message-queue",
|
|
|
|
"serai-primitives",
|
|
|
|
"tokio",
|
2023-07-22 08:04:17 +00:00
|
|
|
"zeroize",
|
2023-07-20 22:53:03 +00:00
|
|
|
]
|
|
|
|
|
2024-09-06 07:20:38 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-monero-processor"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
2024-09-12 22:40:10 +00:00
|
|
|
"ciphersuite",
|
2024-09-06 07:20:38 +00:00
|
|
|
"dalek-ff-group",
|
2024-09-12 22:40:10 +00:00
|
|
|
"dkg",
|
2024-09-06 07:20:38 +00:00
|
|
|
"log",
|
2024-09-12 22:40:10 +00:00
|
|
|
"modular-frost",
|
2024-09-13 04:48:57 +00:00
|
|
|
"monero-simple-request-rpc",
|
2024-09-06 07:20:38 +00:00
|
|
|
"monero-wallet",
|
|
|
|
"parity-scale-codec",
|
2024-09-14 08:24:48 +00:00
|
|
|
"rand_chacha",
|
2024-09-12 22:40:10 +00:00
|
|
|
"rand_core",
|
|
|
|
"serai-client",
|
|
|
|
"serai-processor-bin",
|
|
|
|
"serai-processor-key-gen",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
|
|
|
"serai-processor-scheduler-primitives",
|
|
|
|
"serai-processor-signers",
|
|
|
|
"serai-processor-utxo-scheduler",
|
|
|
|
"serai-processor-utxo-scheduler-primitives",
|
2024-09-13 09:11:07 +00:00
|
|
|
"serai-processor-view-keys",
|
2024-09-06 07:20:38 +00:00
|
|
|
"tokio",
|
|
|
|
"zalloc",
|
2024-09-13 09:11:07 +00:00
|
|
|
"zeroize",
|
2024-09-06 07:20:38 +00:00
|
|
|
]
|
|
|
|
|
2023-04-22 08:38:47 +00:00
|
|
|
[[package]]
|
2023-07-14 17:10:30 +00:00
|
|
|
name = "serai-no-std-tests"
|
2023-04-22 08:38:47 +00:00
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-08-21 12:56:37 +00:00
|
|
|
"bitcoin-serai",
|
2023-04-22 08:38:47 +00:00
|
|
|
"ciphersuite",
|
|
|
|
"dalek-ff-group",
|
2023-05-13 03:24:47 +00:00
|
|
|
"dkg",
|
2023-05-13 08:20:13 +00:00
|
|
|
"dleq",
|
2023-04-22 08:38:47 +00:00
|
|
|
"flexible-transcript",
|
|
|
|
"minimal-ed448",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"monero-wallet-util",
|
2023-04-22 08:38:47 +00:00
|
|
|
"multiexp",
|
|
|
|
"schnorr-signatures",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-node"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"ciphersuite",
|
2023-06-22 10:25:30 +00:00
|
|
|
"clap",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"embedwards25519",
|
2022-07-16 21:49:35 +00:00
|
|
|
"frame-benchmarking",
|
2023-12-19 00:45:08 +00:00
|
|
|
"futures-util",
|
2024-02-09 07:48:44 +00:00
|
|
|
"hex",
|
2022-07-16 21:49:35 +00:00
|
|
|
"jsonrpsee",
|
2024-04-12 04:38:40 +00:00
|
|
|
"libp2p",
|
2024-05-26 00:33:23 +00:00
|
|
|
"log",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pallet-transaction-payment-rpc",
|
2024-03-23 04:09:23 +00:00
|
|
|
"rand_core",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-authority-discovery",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"sc-basic-authorship",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-cli",
|
|
|
|
"sc-client-api",
|
|
|
|
"sc-consensus",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-consensus-babe",
|
|
|
|
"sc-consensus-grandpa",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-executor",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"sc-network",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sc-network-common",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sc-offchain",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sc-rpc-api",
|
|
|
|
"sc-service",
|
|
|
|
"sc-telemetry",
|
|
|
|
"sc-transaction-pool",
|
|
|
|
"sc-transaction-pool-api",
|
2024-02-09 07:48:44 +00:00
|
|
|
"schnorrkel",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"secq256k1",
|
2024-02-09 07:48:44 +00:00
|
|
|
"serai-env",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serai-runtime",
|
|
|
|
"sp-api",
|
|
|
|
"sp-block-builder",
|
|
|
|
"sp-blockchain",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-consensus-babe",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
2023-03-26 22:57:49 +00:00
|
|
|
"sp-io",
|
2024-02-09 07:48:44 +00:00
|
|
|
"sp-keystore",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-timestamp",
|
2022-07-16 21:49:35 +00:00
|
|
|
"substrate-build-script-utils",
|
|
|
|
"substrate-frame-rpc-system",
|
2023-12-23 02:09:18 +00:00
|
|
|
"tokio",
|
2024-02-09 07:48:44 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-orchestrator"
|
|
|
|
version = "0.0.1"
|
|
|
|
dependencies = [
|
|
|
|
"ciphersuite",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"embedwards25519",
|
2024-02-09 07:48:44 +00:00
|
|
|
"flexible-transcript",
|
|
|
|
"hex",
|
|
|
|
"home",
|
|
|
|
"rand_chacha",
|
|
|
|
"rand_core",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"secq256k1",
|
2024-02-09 07:48:44 +00:00
|
|
|
"zalloc",
|
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-01-05 03:52:41 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"ciphersuite",
|
2023-12-07 07:30:09 +00:00
|
|
|
"frame-support",
|
2023-01-05 03:52:41 +00:00
|
|
|
"parity-scale-codec",
|
2024-02-20 01:50:04 +00:00
|
|
|
"rand_core",
|
2023-01-05 03:52:41 +00:00
|
|
|
"scale-info",
|
|
|
|
"serde",
|
2023-07-25 22:09:23 +00:00
|
|
|
"sp-application-crypto",
|
2023-01-05 03:52:41 +00:00
|
|
|
"sp-core",
|
2024-02-20 01:50:04 +00:00
|
|
|
"sp-io",
|
2023-01-28 06:47:13 +00:00
|
|
|
"sp-runtime",
|
2022-11-11 03:35:09 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2024-09-11 22:56:23 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-bin"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"ciphersuite",
|
|
|
|
"dkg",
|
|
|
|
"env_logger",
|
|
|
|
"hex",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"serai-client",
|
|
|
|
"serai-db",
|
|
|
|
"serai-env",
|
|
|
|
"serai-message-queue",
|
|
|
|
"serai-processor-key-gen",
|
|
|
|
"serai-processor-messages",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
|
|
|
"serai-processor-scheduler-primitives",
|
|
|
|
"serai-processor-signers",
|
|
|
|
"tokio",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2024-09-15 02:12:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-ethereum-contracts"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2024-09-15 16:04:57 +00:00
|
|
|
"alloy-sol-macro-expander",
|
|
|
|
"alloy-sol-macro-input",
|
2024-09-15 02:12:32 +00:00
|
|
|
"alloy-sol-types",
|
2024-09-15 02:44:16 +00:00
|
|
|
"build-solidity-contracts",
|
2024-09-15 16:04:57 +00:00
|
|
|
"prettyplease 0.2.22",
|
|
|
|
"serde_json",
|
|
|
|
"syn 2.0.77",
|
|
|
|
"syn-solidity",
|
2024-09-15 02:12:32 +00:00
|
|
|
]
|
|
|
|
|
2024-09-15 21:13:10 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-ethereum-deployer"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"alloy-consensus",
|
|
|
|
"alloy-core",
|
|
|
|
"alloy-provider",
|
|
|
|
"alloy-rpc-types-eth",
|
|
|
|
"alloy-simple-request-transport",
|
|
|
|
"alloy-sol-macro",
|
|
|
|
"alloy-sol-types",
|
|
|
|
"alloy-transport",
|
|
|
|
"build-solidity-contracts",
|
|
|
|
"serai-processor-ethereum-primitives",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-ethereum-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"alloy-consensus",
|
|
|
|
"alloy-core",
|
|
|
|
"group",
|
|
|
|
"k256",
|
|
|
|
]
|
|
|
|
|
2024-08-19 02:43:13 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-frost-attempt-manager"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2024-08-19 04:41:18 +00:00
|
|
|
"borsh",
|
2024-08-19 02:43:13 +00:00
|
|
|
"log",
|
|
|
|
"modular-frost",
|
2024-08-19 04:41:18 +00:00
|
|
|
"parity-scale-codec",
|
2024-08-19 02:43:13 +00:00
|
|
|
"rand_core",
|
|
|
|
"serai-db",
|
|
|
|
"serai-processor-messages",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
]
|
|
|
|
|
2024-08-16 21:01:45 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-key-gen"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"blake2",
|
|
|
|
"borsh",
|
|
|
|
"ciphersuite",
|
|
|
|
"dkg",
|
|
|
|
"ec-divisors",
|
|
|
|
"flexible-transcript",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"rand_chacha",
|
|
|
|
"rand_core",
|
|
|
|
"serai-db",
|
|
|
|
"serai-processor-messages",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-07-03 12:09:41 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-messages"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-07-03 12:09:41 +00:00
|
|
|
"dkg",
|
2024-09-09 02:13:42 +00:00
|
|
|
"hex",
|
2023-09-02 11:53:14 +00:00
|
|
|
"parity-scale-codec",
|
2023-10-19 10:22:21 +00:00
|
|
|
"serai-coins-primitives",
|
2023-07-03 12:09:41 +00:00
|
|
|
"serai-in-instructions-primitives",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
]
|
|
|
|
|
2024-08-20 15:57:56 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"group",
|
2024-08-27 02:57:28 +00:00
|
|
|
"log",
|
2024-08-20 15:57:56 +00:00
|
|
|
"parity-scale-codec",
|
2024-09-01 05:55:04 +00:00
|
|
|
"serai-coins-primitives",
|
2024-08-20 15:57:56 +00:00
|
|
|
"serai-primitives",
|
2024-08-27 02:57:28 +00:00
|
|
|
"tokio",
|
2024-08-20 15:57:56 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-scanner"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"group",
|
|
|
|
"hex",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-08-29 16:45:47 +00:00
|
|
|
"serai-coins-primitives",
|
2024-08-20 15:57:56 +00:00
|
|
|
"serai-db",
|
2024-08-24 01:21:02 +00:00
|
|
|
"serai-in-instructions-primitives",
|
2024-08-20 22:20:28 +00:00
|
|
|
"serai-primitives",
|
2024-08-20 15:57:56 +00:00
|
|
|
"serai-processor-primitives",
|
2024-09-06 07:20:38 +00:00
|
|
|
"serai-processor-scheduler-primitives",
|
2024-08-20 15:57:56 +00:00
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2024-09-02 20:09:52 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-scheduler-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
2024-09-06 07:20:38 +00:00
|
|
|
"ciphersuite",
|
|
|
|
"modular-frost",
|
2024-09-02 20:09:52 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"serai-db",
|
|
|
|
]
|
|
|
|
|
2024-09-06 07:20:38 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-signers"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"ciphersuite",
|
2024-09-09 05:01:29 +00:00
|
|
|
"frost-schnorrkel",
|
2024-09-06 07:20:38 +00:00
|
|
|
"log",
|
|
|
|
"modular-frost",
|
|
|
|
"parity-scale-codec",
|
2024-09-09 05:01:29 +00:00
|
|
|
"rand_core",
|
2024-09-06 07:20:38 +00:00
|
|
|
"serai-db",
|
2024-09-09 05:01:29 +00:00
|
|
|
"serai-in-instructions-primitives",
|
2024-09-09 08:18:54 +00:00
|
|
|
"serai-primitives",
|
2024-09-06 07:20:38 +00:00
|
|
|
"serai-processor-frost-attempt-manager",
|
|
|
|
"serai-processor-messages",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
|
|
|
"serai-processor-scheduler-primitives",
|
|
|
|
"serai-validator-sets-primitives",
|
|
|
|
"tokio",
|
2024-09-07 07:33:26 +00:00
|
|
|
"zeroize",
|
2024-09-06 07:20:38 +00:00
|
|
|
]
|
|
|
|
|
2024-09-14 09:20:02 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-smart-contract-scheduler"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"group",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"serai-db",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
|
|
|
"serai-processor-scheduler-primitives",
|
|
|
|
]
|
|
|
|
|
2023-07-21 18:01:58 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-tests"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-07-25 00:06:05 +00:00
|
|
|
"bitcoin-serai",
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-07-21 18:01:58 +00:00
|
|
|
"ciphersuite",
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
2023-07-21 18:01:58 +00:00
|
|
|
"dkg",
|
|
|
|
"dockertest",
|
2024-05-14 05:42:18 +00:00
|
|
|
"ethereum-serai",
|
2023-07-21 18:01:58 +00:00
|
|
|
"hex",
|
2024-05-21 04:29:33 +00:00
|
|
|
"k256",
|
Clean the Monero lib for auditing (#577)
* Remove unsafe creation of dalek_ff_group::EdwardsPoint in BP+
* Rename Bulletproofs to Bulletproof, since they are a single Bulletproof
Also bifurcates prove with prove_plus, and adds a few documentation items.
* Make CLSAG signing private
Also adds a bit more documentation and does a bit more tidying.
* Remove the distribution cache
It's a notable bandwidth/performance improvement, yet it's not ready. We need a
dedicated Distribution struct which is managed by the wallet and passed in.
While we can do that now, it's not currently worth the effort.
* Tidy Borromean/MLSAG a tad
* Remove experimental feature from monero-serai
* Move amount_decryption into EncryptedAmount::decrypt
* Various RingCT doc comments
* Begin crate smashing
* Further documentation, start shoring up API boundaries of existing crates
* Document and clean clsag
* Add a dedicated send/recv CLSAG mask struct
Abstracts the types used internally.
Also moves the tests from monero-serai to monero-clsag.
* Smash out monero-bulletproofs
Removes usage of dalek-ff-group/multiexp for curve25519-dalek.
Makes compiling in the generators an optional feature.
Adds a structured batch verifier which should be notably more performant.
Documentation and clean up still necessary.
* Correct no-std builds for monero-clsag and monero-bulletproofs
* Tidy and document monero-bulletproofs
I still don't like the impl of the original Bulletproofs...
* Error if missing documentation
* Smash out MLSAG
* Smash out Borromean
* Tidy up monero-serai as a meta crate
* Smash out RPC, wallet
* Document the RPC
* Improve docs a bit
* Move Protocol to monero-wallet
* Incomplete work on using Option to remove panic cases
* Finish documenting monero-serai
* Remove TODO on reading pseudo_outs for AggregateMlsagBorromean
* Only read transactions with one Input::Gen or all Input::ToKey
Also adds a helper to fetch a transaction's prefix.
* Smash out polyseed
* Smash out seed
* Get the repo to compile again
* Smash out Monero addresses
* Document cargo features
Credit to @hinto-janai for adding such sections to their work on documenting
monero-serai in #568.
* Fix deserializing v2 miner transactions
* Rewrite monero-wallet's send code
I have yet to redo the multisig code and the builder. This should be much
cleaner, albeit slower due to redoing work.
This compiles with clippy --all-features. I have to finish the multisig/builder
for --all-targets to work (and start updating the rest of Serai).
* Add SignableTransaction Read/Write
* Restore Monero multisig TX code
* Correct invalid RPC type def in monero-rpc
* Update monero-wallet tests to compile
Some are _consistently_ failing due to the inputs we attempt to spend being too
young. I'm unsure what's up with that. Most seem to pass _consistently_,
implying it's not a random issue yet some configuration/env aspect.
* Clean and document monero-address
* Sync rest of repo with monero-serai changes
* Represent height/block number as a u32
* Diversify ViewPair/Scanner into ViewPair/GuaranteedViewPair and Scanner/GuaranteedScanner
Also cleans the Scanner impl.
* Remove non-small-order view key bound
Guaranteed addresses are in fact guaranteed even with this due to prefixing key
images causing zeroing the ECDH to not zero the shared key.
* Finish documenting monero-serai
* Correct imports for no-std
* Remove possible panic in monero-serai on systems < 32 bits
This was done by requiring the system's usize can represent a certain number.
* Restore the reserialize chain binary
* fmt, machete, GH CI
* Correct misc TODOs in monero-serai
* Have Monero test runner evaluate an Eventuality for all signed TXs
* Fix a pair of bugs in the decoy tests
Unfortunately, this test is still failing.
* Fix remaining bugs in monero-wallet tests
* Reject torsioned spend keys to ensure we can spend the outputs we scan
* Tidy inlined epee code in the RPC
* Correct the accidental swap of stagenet/testnet address bytes
* Remove unused dep from processor
* Handle Monero fee logic properly in the processor
* Document v2 TX/RCT output relation assumed when scanning
* Adjust how we mine the initial blocks due to some CI test failures
* Fix weight estimation for RctType::ClsagBulletproof TXs
* Again increase the amount of blocks we mine prior to running tests
* Correct the if check about when to mine blocks on start
Finally fixes the lack of decoy candidates failures in CI.
* Run Monero on Debian, even for internal testnets
Change made due to a segfault incurred when locally testing.
https://github.com/monero-project/monero/issues/9141 for the upstream.
* Don't attempt running tests on the verify-chain binary
Adds a minimum XMR fee to the processor and runs fmt.
* Increase minimum Monero fee in processor
I'm truly unsure why this is required right now.
* Distinguish fee from necessary_fee in monero-wallet
If there's no change, the fee is difference of the inputs to the outputs. The
prior code wouldn't check that amount is greater than or equal to the necessary
fee, and returning the would-be change amount as the fee isn't necessarily
helpful.
Now the fee is validated in such cases and the necessary fee is returned,
enabling operating off of that.
* Restore minimum Monero fee from develop
2024-07-07 10:57:18 +00:00
|
|
|
"monero-simple-request-rpc",
|
|
|
|
"monero-wallet",
|
2023-07-26 18:02:17 +00:00
|
|
|
"parity-scale-codec",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-07-29 08:26:24 +00:00
|
|
|
"serai-client",
|
2024-05-14 05:42:18 +00:00
|
|
|
"serai-db",
|
2023-07-21 18:01:58 +00:00
|
|
|
"serai-docker-tests",
|
|
|
|
"serai-message-queue",
|
|
|
|
"serai-message-queue-tests",
|
|
|
|
"serai-processor-messages",
|
|
|
|
"serde_json",
|
|
|
|
"tokio",
|
2023-07-22 08:04:17 +00:00
|
|
|
"zeroize",
|
2023-07-21 18:01:58 +00:00
|
|
|
]
|
|
|
|
|
2024-09-01 04:01:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-transaction-chaining-scheduler"
|
|
|
|
version = "0.1.0"
|
2024-09-01 05:55:04 +00:00
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"group",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"serai-db",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
2024-09-02 20:09:52 +00:00
|
|
|
"serai-processor-scheduler-primitives",
|
2024-09-01 05:55:04 +00:00
|
|
|
"serai-processor-utxo-scheduler-primitives",
|
|
|
|
]
|
2024-09-01 04:01:01 +00:00
|
|
|
|
2024-09-04 07:54:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-utxo-scheduler"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"group",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"serai-db",
|
|
|
|
"serai-primitives",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
|
|
|
"serai-processor-scheduler-primitives",
|
|
|
|
"serai-processor-utxo-scheduler-primitives",
|
|
|
|
]
|
|
|
|
|
2024-09-01 04:01:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-utxo-scheduler-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2024-09-04 07:54:12 +00:00
|
|
|
"borsh",
|
2024-09-01 04:01:01 +00:00
|
|
|
"serai-primitives",
|
|
|
|
"serai-processor-primitives",
|
|
|
|
"serai-processor-scanner",
|
2024-09-03 05:41:51 +00:00
|
|
|
"serai-processor-scheduler-primitives",
|
2024-09-01 04:01:01 +00:00
|
|
|
]
|
|
|
|
|
2024-09-04 21:29:48 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-processor-view-keys"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"ciphersuite",
|
|
|
|
]
|
|
|
|
|
2023-07-27 18:19:03 +00:00
|
|
|
[[package]]
|
2023-07-28 03:38:04 +00:00
|
|
|
name = "serai-reproducible-runtime-tests"
|
2023-07-27 18:19:03 +00:00
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"dockertest",
|
|
|
|
"hex",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-07-27 18:19:03 +00:00
|
|
|
"serai-docker-tests",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-runtime"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-benchmarking",
|
|
|
|
"frame-executive",
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"frame-system-rpc-runtime-api",
|
2024-05-21 10:09:04 +00:00
|
|
|
"hashbrown 0.14.5",
|
2023-12-16 22:44:08 +00:00
|
|
|
"pallet-authorship",
|
2023-03-26 12:43:01 +00:00
|
|
|
"pallet-babe",
|
|
|
|
"pallet-grandpa",
|
|
|
|
"pallet-timestamp",
|
2022-07-16 21:49:35 +00:00
|
|
|
"pallet-transaction-payment",
|
|
|
|
"pallet-transaction-payment-rpc-runtime-api",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2024-06-02 23:58:29 +00:00
|
|
|
"serai-abi",
|
2023-10-19 10:22:21 +00:00
|
|
|
"serai-coins-pallet",
|
2023-11-05 17:02:34 +00:00
|
|
|
"serai-dex-pallet",
|
2024-08-31 22:55:42 +00:00
|
|
|
"serai-economic-security-pallet",
|
2024-08-15 03:12:04 +00:00
|
|
|
"serai-emissions-pallet",
|
2024-07-18 23:30:19 +00:00
|
|
|
"serai-genesis-liquidity-pallet",
|
2023-07-03 12:09:41 +00:00
|
|
|
"serai-in-instructions-pallet",
|
2023-01-06 00:36:49 +00:00
|
|
|
"serai-primitives",
|
2023-10-22 00:06:53 +00:00
|
|
|
"serai-signals-pallet",
|
2023-07-03 12:09:41 +00:00
|
|
|
"serai-validator-sets-pallet",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-api",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-authority-discovery",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-block-builder",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-consensus-babe",
|
|
|
|
"sp-consensus-grandpa",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-offchain",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-session",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-transaction-pool",
|
|
|
|
"sp-version",
|
|
|
|
"substrate-wasm-builder",
|
2023-07-03 12:09:41 +00:00
|
|
|
]
|
|
|
|
|
2023-10-22 00:06:53 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-signals-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2023-11-25 00:56:57 +00:00
|
|
|
"serai-in-instructions-pallet",
|
2023-10-22 00:06:53 +00:00
|
|
|
"serai-primitives",
|
2023-12-06 14:53:48 +00:00
|
|
|
"serai-signals-primitives",
|
2023-10-22 00:06:53 +00:00
|
|
|
"serai-validator-sets-pallet",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
|
|
|
]
|
|
|
|
|
2023-12-06 14:53:48 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-signals-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"borsh",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-primitives",
|
|
|
|
"serde",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-07-03 12:09:41 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serai-validator-sets-pallet"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"bitvec",
|
2023-07-03 12:09:41 +00:00
|
|
|
"frame-support",
|
|
|
|
"frame-system",
|
2023-11-22 11:22:46 +00:00
|
|
|
"pallet-babe",
|
|
|
|
"pallet-grandpa",
|
2023-07-03 12:09:41 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2023-10-22 07:59:21 +00:00
|
|
|
"serai-coins-pallet",
|
2023-12-05 13:52:50 +00:00
|
|
|
"serai-dex-pallet",
|
2023-07-03 12:09:41 +00:00
|
|
|
"serai-primitives",
|
|
|
|
"serai-validator-sets-primitives",
|
One Round DKG (#589)
* Upstream GBP, divisor, circuit abstraction, and EC gadgets from FCMP++
* Initial eVRF implementation
Not quite done yet. It needs to communicate the resulting points and proofs to
extract them from the Pedersen Commitments in order to return those, and then
be tested.
* Add the openings of the PCs to the eVRF as necessary
* Add implementation of secq256k1
* Make DKG Encryption a bit more flexible
No longer requires the use of an EncryptionKeyMessage, and allows pre-defined
keys for encryption.
* Make NUM_BITS an argument for the field macro
* Have the eVRF take a Zeroizing private key
* Initial eVRF-based DKG
* Add embedwards25519 curve
* Inline the eVRF into the DKG library
Due to how we're handling share encryption, we'd either need two circuits or to
dedicate this circuit to the DKG. The latter makes sense at this time.
* Add documentation to the eVRF-based DKG
* Add paragraph claiming robustness
* Update to the new eVRF proof
* Finish routing the eVRF functionality
Still needs errors and serialization, along with a few other TODOs.
* Add initial eVRF DKG test
* Improve eVRF DKG
Updates how we calculcate verification shares, improves performance when
extracting multiple sets of keys, and adds more to the test for it.
* Start using a proper error for the eVRF DKG
* Resolve various TODOs
Supports recovering multiple key shares from the eVRF DKG.
Inlines two loops to save 2**16 iterations.
Adds support for creating a constant time representation of scalars < NUM_BITS.
* Ban zero ECDH keys, document non-zero requirements
* Implement eVRF traits, all the way up to the DKG, for secp256k1/ed25519
* Add Ristretto eVRF trait impls
* Support participating multiple times in the eVRF DKG
* Only participate once per key, not once per key share
* Rewrite processor key-gen around the eVRF DKG
Still a WIP.
* Finish routing the new key gen in the processor
Doesn't touch the tests, coordinator, nor Substrate yet.
`cargo +nightly fmt && cargo +nightly-2024-07-01 clippy --all-features -p serai-processor`
does pass.
* Deduplicate and better document in processor key_gen
* Update serai-processor tests to the new key gen
* Correct amount of yx coefficients, get processor key gen test to pass
* Add embedded elliptic curve keys to Substrate
* Update processor key gen tests to the eVRF DKG
* Have set_keys take signature_participants, not removed_participants
Now no one is removed from the DKG. Only `t` people publish the key however.
Uses a BitVec for an efficient encoding of the participants.
* Update the coordinator binary for the new DKG
This does not yet update any tests.
* Add sensible Debug to key_gen::[Processor, Coordinator]Message
* Have the DKG explicitly declare how to interpolate its shares
Removes the hack for MuSig where we multiply keys by the inverse of their
lagrange interpolation factor.
* Replace Interpolation::None with Interpolation::Constant
Allows the MuSig DKG to keep the secret share as the original private key,
enabling deriving FROST nonces consistently regardless of the MuSig context.
* Get coordinator tests to pass
* Update spec to the new DKG
* Get clippy to pass across the repo
* cargo machete
* Add an extra sleep to ensure expected ordering of `Participation`s
* Update orchestration
* Remove bad panic in coordinator
It expected ConfirmationShare to be n-of-n, not t-of-n.
* Improve documentation on functions
* Update TX size limit
We now no longer have to support the ridiculous case of having 49 DKG
participations within a 101-of-150 DKG. It does remain quite high due to
needing to _sign_ so many times. It'd may be optimal for parties with multiple
key shares to independently send their preprocesses/shares (despite the
overhead that'll cause with signatures and the transaction structure).
* Correct error in the Processor spec document
* Update a few comments in the validator-sets pallet
* Send/Recv Participation one at a time
Sending all, then attempting to receive all in an expected order, wasn't working
even with notable delays between sending messages. This points to the mempool
not working as expected...
* Correct ThresholdKeys serialization in modular-frost test
* Updating existing TX size limit test for the new DKG parameters
* Increase time allowed for the DKG on the GH CI
* Correct construction of signature_participants in serai-client tests
Fault identified by akil.
* Further contextualize DkgConfirmer by ValidatorSet
Caught by a safety check we wouldn't reuse preprocesses across messages. That
raises the question of we were prior reusing preprocesses (reusing keys)?
Except that'd have caused a variety of signing failures (suggesting we had some
staggered timing avoiding it in practice but yes, this was possible in theory).
* Add necessary calls to set_embedded_elliptic_curve_key in coordinator set rotation tests
* Correct shimmed setting of a secq256k1 key
* cargo fmt
* Don't use `[0; 32]` for the embedded keys in the coordinator rotation test
The key_gen function expects the random values already decided.
* Big-endian secq256k1 scalars
Also restores the prior, safer, Encryption::register function.
2024-08-16 18:26:07 +00:00
|
|
|
"serde",
|
2023-07-03 12:09:41 +00:00
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-core",
|
2023-10-10 10:53:24 +00:00
|
|
|
"sp-io",
|
2023-10-16 19:07:39 +00:00
|
|
|
"sp-runtime",
|
2023-11-22 11:22:46 +00:00
|
|
|
"sp-session",
|
2023-12-16 22:44:08 +00:00
|
|
|
"sp-staking",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-07-03 12:09:41 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serai-validator-sets-primitives"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-11-25 09:01:11 +00:00
|
|
|
"borsh",
|
2023-07-03 12:09:41 +00:00
|
|
|
"ciphersuite",
|
|
|
|
"dkg",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serai-primitives",
|
|
|
|
"serde",
|
|
|
|
"sp-core",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-07-03 12:09:41 +00:00
|
|
|
"zeroize",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serde"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.209"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "99fce0ffe7310761ca6bf9faf5115afbc19688edd00171d81b1bb1b116c63e09"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde_derive",
|
|
|
|
]
|
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serde_bytes"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.11.15"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "387cc504cb06bb40a96c8e04e951fe01854cf6bc921053c954e4a606d9675c6a"
|
2023-04-08 08:44:28 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serde_derive"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.209"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "a5831b979fd7b5439637af1752d535ff49f4860c0f341d1baeb6faf0f4242170"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "serde_json"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.0.128"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "6ff5456707a1de34e7e37f2a6fd3d3f808c318259cbd01ab6377795054b483d8"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-10-20 05:05:36 +00:00
|
|
|
"itoa",
|
2024-08-01 08:06:09 +00:00
|
|
|
"memchr",
|
2022-07-16 21:49:35 +00:00
|
|
|
"ryu",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2023-10-23 10:59:38 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serde_repr"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "0.1.19"
|
2023-10-23 10:59:38 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "6c64451ba24fc7a6a2d60fc75dd9c83c90903b19028d4eff35e88fc1e86564e9"
|
2023-10-23 10:59:38 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-10-23 10:59:38 +00:00
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serde_spanned"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.6.7"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "eb5b1b31579f3811bf615c144393417496f152e12ac8b7663bf664f4a815306d"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serde_urlencoded"
|
|
|
|
version = "0.7.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d3491c14715ca2294c4d6a88f15e84739788c1d030eed8c110436aafdaa2f3fd"
|
|
|
|
dependencies = [
|
|
|
|
"form_urlencoded",
|
2022-10-20 05:05:36 +00:00
|
|
|
"itoa",
|
2022-07-16 21:49:35 +00:00
|
|
|
"ryu",
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2023-07-20 22:53:03 +00:00
|
|
|
[[package]]
|
|
|
|
name = "serde_with"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "3.9.0"
|
2023-07-20 22:53:03 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "69cecfa94848272156ea67b2b1a53f20fc7bc638c4a46d2f8abde08f05f4b857"
|
2023-07-20 22:53:03 +00:00
|
|
|
dependencies = [
|
2024-05-21 10:09:04 +00:00
|
|
|
"base64 0.22.1",
|
2023-10-23 10:59:38 +00:00
|
|
|
"chrono",
|
|
|
|
"hex",
|
|
|
|
"indexmap 1.9.3",
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2023-07-20 22:53:03 +00:00
|
|
|
"serde",
|
2024-02-25 23:37:15 +00:00
|
|
|
"serde_derive",
|
2023-10-23 10:59:38 +00:00
|
|
|
"serde_json",
|
|
|
|
"time",
|
2023-07-20 22:53:03 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sha-1"
|
2022-08-16 07:44:32 +00:00
|
|
|
version = "0.9.8"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-08-16 07:44:32 +00:00
|
|
|
checksum = "99cd6713db3cf16b6c84e06321e049a9b9f699826e16096d23bbcc44d15d51a6"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-08-16 07:44:32 +00:00
|
|
|
"block-buffer 0.9.0",
|
|
|
|
"cfg-if",
|
|
|
|
"cpufeatures",
|
|
|
|
"digest 0.9.0",
|
2023-04-08 08:44:28 +00:00
|
|
|
"opaque-debug",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-07-28 03:38:04 +00:00
|
|
|
[[package]]
|
2023-11-06 12:19:55 +00:00
|
|
|
name = "sha1"
|
|
|
|
version = "0.10.6"
|
2023-07-28 03:38:04 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-06 12:19:55 +00:00
|
|
|
checksum = "e3bf829a2d51ab4a5ddf1352d8470c140cadc8301b2ae1789db023f01cedd6ba"
|
2023-07-28 03:38:04 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"cpufeatures",
|
|
|
|
"digest 0.10.7",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sha2"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.10.8"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "793db75ad2bcafc3ffa7c68b215fee268f537982cd901d132f89c6343f3a3dc8"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"cpufeatures",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sha3"
|
2023-05-10 11:34:07 +00:00
|
|
|
version = "0.10.8"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-05-10 11:34:07 +00:00
|
|
|
checksum = "75872d278a8f37ef87fa0ddbda7802605cb18344497949862c0d4dcb291eba60"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
"keccak",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sha3-asm"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.3"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "57d79b758b7cb2085612b11a235055e485605a5103faccdd633f35bd7aee69dd"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
|
|
|
"cfg-if",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sharded-slab"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.1.7"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "f40ca3c46823713e0d4209592e8d6e826aa57e928f09752619fc696c499637f6"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "shlex"
|
2024-01-23 03:08:37 +00:00
|
|
|
version = "1.3.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-23 03:08:37 +00:00
|
|
|
checksum = "0fda2ff0d084019ba4d7c6f371c95d8fd75ce3524c3cb8fb653a3023f6323e64"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "signal-hook-registry"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "1.4.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "a9e9e0b4211b72e7b8b6e85c807d36c212bdb33ea8587f7569562a84df5465b1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2023-03-06 13:22:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "signature"
|
2023-11-20 04:52:32 +00:00
|
|
|
version = "2.2.0"
|
2023-03-06 13:22:04 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-20 04:52:32 +00:00
|
|
|
checksum = "77549399552de45a898a580c1b41d445bf730df867cc44e6c0233bbc4b8329de"
|
2023-03-06 13:22:04 +00:00
|
|
|
dependencies = [
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
2023-10-16 19:07:39 +00:00
|
|
|
"rand_core",
|
2023-03-06 13:22:04 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "simba"
|
2023-04-08 08:44:28 +00:00
|
|
|
version = "0.8.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-08 08:44:28 +00:00
|
|
|
checksum = "061507c94fc6ab4ba1c9a0305018408e312e17c041eb63bef8aa726fa33aceae"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"approx",
|
|
|
|
"num-complex",
|
|
|
|
"num-traits",
|
|
|
|
"paste",
|
2023-03-06 12:39:43 +00:00
|
|
|
"wide",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-11-06 14:14:46 +00:00
|
|
|
[[package]]
|
|
|
|
name = "simple-request"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
|
|
|
"base64ct",
|
2024-01-17 00:32:30 +00:00
|
|
|
"http-body-util",
|
2024-07-15 00:27:36 +00:00
|
|
|
"hyper 1.4.1",
|
2023-11-06 14:14:46 +00:00
|
|
|
"hyper-rustls",
|
2024-01-17 00:32:30 +00:00
|
|
|
"hyper-util",
|
2023-11-06 14:14:46 +00:00
|
|
|
"tokio",
|
2024-01-17 00:32:30 +00:00
|
|
|
"tower-service",
|
2023-11-06 14:14:46 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "siphasher"
|
2023-08-23 17:24:21 +00:00
|
|
|
version = "0.3.11"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 17:24:21 +00:00
|
|
|
checksum = "38b58827f4464d87d377d175e90bf58eb00fd8716ff0a62f80356b5e61555d0d"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "slab"
|
2023-08-23 02:06:06 +00:00
|
|
|
version = "0.4.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 02:06:06 +00:00
|
|
|
checksum = "8f92a496fb766b417c996b9c5e57daf2f7ad3b0bebe1ccfca4856390e3d3bb67"
|
2022-07-22 16:36:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"autocfg",
|
|
|
|
]
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "slice-group-by"
|
2023-05-10 11:34:07 +00:00
|
|
|
version = "0.3.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-05-10 11:34:07 +00:00
|
|
|
checksum = "826167069c09b99d56f31e9ae5c99049e932a98c9dc2dac47645b08dbbf76ba7"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "smallvec"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "1.13.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "3c5e1a9a646d36c3599cd173a41282daf47c44583ad367b8e6837255952e5c67"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "snap"
|
2023-12-06 09:51:40 +00:00
|
|
|
version = "1.1.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-06 09:51:40 +00:00
|
|
|
checksum = "1b6b67fb9a61334225b5b790716f609cd58395f895b3fe8b328786812a40bc3b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "snow"
|
2024-02-04 06:13:48 +00:00
|
|
|
version = "0.9.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-04 06:13:48 +00:00
|
|
|
checksum = "850948bee068e713b8ab860fe1adc4d109676ab4c3b621fd8147f06b261f2f85"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"aes-gcm",
|
2022-07-16 21:49:35 +00:00
|
|
|
"blake2",
|
|
|
|
"chacha20poly1305",
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
|
|
|
"rand_core",
|
2024-02-25 23:37:15 +00:00
|
|
|
"ring 0.17.8",
|
2024-09-05 21:03:23 +00:00
|
|
|
"rustc_version 0.4.1",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "socket2"
|
2023-10-23 04:33:38 +00:00
|
|
|
version = "0.4.10"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-23 04:33:38 +00:00
|
|
|
checksum = "9f7916fc008ca5542385b89a3d3ce689953c143e9304a9bf8beec1de48994c0d"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
2023-06-22 10:25:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "socket2"
|
2024-05-21 10:09:04 +00:00
|
|
|
version = "0.5.7"
|
2023-06-22 10:25:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 10:09:04 +00:00
|
|
|
checksum = "ce305eb0b4296696835b71df73eb912e0f1ffd2556a501fcede6e0c50349191c"
|
2023-06-22 10:25:30 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
2024-03-08 04:21:15 +00:00
|
|
|
"windows-sys 0.52.0",
|
2023-06-22 10:25:30 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "soketto"
|
|
|
|
version = "0.7.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "41d1c5305e39e09653383c2c7244f2f78b3bcae37cf50c64cb4789c9f5096ec2"
|
|
|
|
dependencies = [
|
2022-10-22 01:40:50 +00:00
|
|
|
"base64 0.13.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"bytes",
|
|
|
|
"futures",
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2022-07-16 21:49:35 +00:00
|
|
|
"httparse",
|
|
|
|
"log",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-11-06 12:19:55 +00:00
|
|
|
"sha-1",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2024-07-18 19:18:08 +00:00
|
|
|
[[package]]
|
|
|
|
name = "soketto"
|
|
|
|
version = "0.8.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "37468c595637c10857701c990f93a40ce0e357cedb0953d1c26c8d8027f9bb53"
|
|
|
|
dependencies = [
|
|
|
|
"base64 0.22.1",
|
|
|
|
"bytes",
|
|
|
|
"futures",
|
|
|
|
"httparse",
|
|
|
|
"log",
|
|
|
|
"rand",
|
|
|
|
"sha1",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-api"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"hash-db",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2023-05-01 07:17:37 +00:00
|
|
|
"scale-info",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-api-proc-macro",
|
|
|
|
"sp-core",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sp-externalities",
|
2023-05-01 07:17:37 +00:00
|
|
|
"sp-metadata-ir",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-runtime",
|
|
|
|
"sp-state-machine",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-trie",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-version",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-api-proc-macro"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-03-26 12:43:01 +00:00
|
|
|
"Inflector",
|
2022-07-16 21:49:35 +00:00
|
|
|
"blake2",
|
2023-03-26 12:43:01 +00:00
|
|
|
"expander",
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-application-crypto"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "23.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-arithmetic"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "16.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"integer-sqrt",
|
|
|
|
"num-traits",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"static_assertions",
|
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-authority-discovery"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"sp-api",
|
|
|
|
"sp-application-crypto",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-03-26 12:43:01 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-block-builder"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"sp-api",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-blockchain"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-07-19 02:30:55 +00:00
|
|
|
"schnellru",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-api",
|
|
|
|
"sp-consensus",
|
|
|
|
"sp-database",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-state-machine",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-consensus"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"futures",
|
|
|
|
"log",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-runtime",
|
|
|
|
"sp-state-machine",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
2023-03-26 12:43:01 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-consensus-babe"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-api",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-consensus-slots",
|
|
|
|
"sp-core",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-timestamp",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-consensus-grandpa"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"finality-grandpa",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-api",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-core",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-03-26 12:43:01 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-consensus-slots"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-03-26 12:43:01 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-03-26 12:43:01 +00:00
|
|
|
"sp-timestamp",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-core"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "21.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"array-bytes",
|
2023-06-28 18:57:58 +00:00
|
|
|
"bitflags 1.3.2",
|
2022-09-29 18:33:09 +00:00
|
|
|
"blake2",
|
2023-03-06 12:39:43 +00:00
|
|
|
"bounded-collections",
|
2023-08-23 17:24:21 +00:00
|
|
|
"bs58",
|
2022-07-16 21:49:35 +00:00
|
|
|
"dyn-clonable",
|
2022-09-29 18:33:09 +00:00
|
|
|
"ed25519-zebra",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures",
|
|
|
|
"hash-db",
|
|
|
|
"hash256-std-hasher",
|
2023-01-05 03:52:41 +00:00
|
|
|
"impl-serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
"lazy_static",
|
|
|
|
"log",
|
2023-04-08 08:44:28 +00:00
|
|
|
"merlin",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-05-01 07:17:37 +00:00
|
|
|
"paste",
|
2022-12-07 23:05:06 +00:00
|
|
|
"primitive-types",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"regex",
|
|
|
|
"scale-info",
|
|
|
|
"schnorrkel",
|
|
|
|
"secrecy",
|
|
|
|
"serde",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-core-hashing",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-debug-derive",
|
|
|
|
"sp-externalities",
|
|
|
|
"sp-runtime-interface",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-storage",
|
|
|
|
"ss58-registry",
|
|
|
|
"substrate-bip39",
|
|
|
|
"thiserror",
|
|
|
|
"tiny-bip39",
|
2023-07-19 02:30:55 +00:00
|
|
|
"tracing",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
Processor (#259)
* Initial work on a message box
* Finish message-box (untested)
* Expand documentation
* Embed the recipient in the signature challenge
Prevents a message from A -> B from being read as from A -> C.
* Update documentation by bifurcating sender/receiver
* Panic on receiving an invalid signature
If we've received an invalid signature in an authenticated system, a
service is malicious, critically faulty (equivalent to malicious), or
the message layer has been compromised (or is otherwise critically
faulty).
Please note a receiver who handles a message they shouldn't will trigger
this. That falls under being critically faulty.
* Documentation and helper methods
SecureMessage::new and SecureMessage::serialize.
Secure Debug for MessageBox.
* Have SecureMessage not be serialized by default
Allows passing around in-memory, if desired, and moves the error from
decrypt to new (which performs deserialization).
Decrypt no longer has an error since it panics if given an invalid
signature, due to this being intranet code.
* Explain and improve nonce handling
Includes a missing zeroize call.
* Rebase to latest develop
Updates to transcript 0.2.0.
* Add a test for the MessageBox
* Export PrivateKey and PublicKey
* Also test serialization
* Add a key_gen binary to message_box
* Have SecureMessage support Serde
* Add encrypt_to_bytes and decrypt_from_bytes
* Support String ser via base64
* Rename encrypt/decrypt to encrypt_bytes/decrypt_to_bytes
* Directly operate with values supporting Borsh
* Use bincode instead of Borsh
By staying inside of serde, we'll support many more structs. While
bincode isn't canonical, we don't need canonicity on an authenticated,
internal system.
* Turn PrivateKey, PublicKey into structs
Uses Zeroizing for the PrivateKey per #150.
* from_string functions intended for loading from an env
* Use &str for PublicKey from_string (now from_str)
The PrivateKey takes the String to take ownership of its memory and
zeroize it. That isn't needed with PublicKeys.
* Finish updating from develop
* Resolve warning
* Use ZeroizingAlloc on the key_gen binary
* Move message-box from crypto/ to common/
* Move key serialization functions to ser
* add/remove functions in MessageBox
* Implement Hash on dalek_ff_group Points
* Make MessageBox generic to its key
Exposes a &'static str variant for internal use and a RistrettoPoint
variant for external use.
* Add Private to_string as deprecated
Stub before more competent tooling is deployed.
* Private to_public
* Test both Internal and External MessageBox, only use PublicKey in the pub API
* Remove panics on invalid signatures
Leftover from when this was solely internal which is now unsafe.
* Chicken scratch a Scanner task
* Add a write function to the DKG library
Enables writing directly to a file.
Also modifies serialize to return Zeroizing<Vec<u8>> instead of just Vec<u8>.
* Make dkg::encryption pub
* Remove encryption from MessageBox
* Use a 64-bit block number in Substrate
We use a 64-bit block number in general since u32 only works for 120 years
(with a 1 second block time). As some chains even push the 1 second threshold,
especially ones based on DAG consensus, this becomes potentially as low as 60
years.
While that should still be plenty, it's not worth wondering/debating. Since
Serai uses 64-bit block numbers elsewhere, this ensures consistency.
* Misc crypto lints
* Get the scanner scratch to compile
* Initial scanner test
* First few lines of scheduler
* Further work on scheduler, solidify API
* Define Scheduler TX format
* Branch creation algorithm
* Document when the branch algorithm isn't perfect
* Only scanned confirmed blocks
* Document Coin
* Remove Canonical/ChainNumber from processor
The processor should be abstracted from canonical numbers thanks to the
coordinator, making this unnecessary.
* Add README documenting processor flow
* Use Zeroize on substrate primitives
* Define messages from/to the processor
* Correct over-specified versioning
* Correct build re: in_instructions::primitives
* Debug/some serde in crypto/
* Use a struct for ValidatorSetInstance
* Add a processor key_gen task
Redos DB handling code.
* Replace trait + impl with wrapper struct
* Add a key confirmation flow to the key gen task
* Document concerns on key_gen
* Start on a signer task
* Add Send to FROST traits
* Move processor lib.rs to main.rs
Adds a dummy main to reduce clippy dead_code warnings.
* Further flesh out main.rs
* Move the DB trait to AsRef<[u8]>
* Signer task
* Remove a panic in bitcoin when there's insufficient funds
Unchecked underflow.
* Have Monero's mine_block mine one block, not 10
It was initially a nicety to deal with the 10 block lock. C::CONFIRMATIONS
should be used for that instead.
* Test signer
* Replace channel expects with log statements
The expects weren't problematic and had nicer code. They just clutter test
output.
* Remove the old wallet file
It predates the coordinator design and shouldn't be used.
* Rename tests/scan.rs to tests/scanner.rs
* Add a wallet test
Complements the recently removed wallet file by adding a test for the scanner,
scheduler, and signer together.
* Work on a run function
Triggers a clippy ICE.
* Resolve clippy ICE
The issue was the non-fully specified lambda in signer.
* Add KeyGenEvent and KeyGenOrder
Needed so we get KeyConfirmed messages from the key gen task.
While we could've read the CoordinatorMessage to see that, routing through the
key gen tasks ensures we only handle it once it's been successfully saved to
disk.
* Expand scanner test
* Clarify processor documentation
* Have the Scanner load keys on boot/save outputs to disk
* Use Vec<u8> for Block ID
Much more flexible.
* Panic if we see the same output multiple times
* Have the Scanner DB mark itself as corrupt when doing a multi-put
This REALLY should be a TX. Since we don't have a TX API right now, this at
least offers detection.
* Have DST'd DB keys accept AsRef<[u8]>
* Restore polling all signers
Writes a custom future to do so.
Also loads signers on boot using what the scanner claims are active keys.
* Schedule OutInstructions
Adds a data field to Payment.
Also cleans some dead code.
* Panic if we create an invalid transaction
Saves the TX once it's successfully signed so if we do panic, we have a copy.
* Route coordinator messages to their respective signer
Requires adding key to the SignId.
* Send SignTransaction orders for all plans
* Add a timer to retry sign_plans when prepare_send fails
* Minor fmt'ing
* Basic Fee API
* Move the change key into Plan
* Properly route activation_number
* Remove ScannerEvent::Block
It's not used under current designs
* Nicen logs
* Add utilities to get a block's number
* Have main issue AckBlock
Also has a few misc lints.
* Parse instructions out of outputs
* Tweak TODOs and remove an unwrap
* Update Bitcoin max input/output quantity
* Only read one piece of data from Monero
Due to output randomization, it's infeasible.
* Embed plan IDs into the TXs they create
We need to stop attempting signing if we've already signed a protocol. Ideally,
any one of the participating signers should be able to provide a proof the TX
was successfully signed. We can't just run a second signing protocol though as
a single malicious signer could complete the TX signature, and publish it,
yet not complete the secondary signature.
The TX itself has to be sufficient to show that the TX matches the plan. This
is done by embedding the ID, so matching addresses/amounts plans are
distinguished, and by allowing verification a TX actually matches a set of
addresses/amounts.
For Monero, this will need augmenting with the ephemeral keys (or usage of a
static seed for them).
* Don't use OP_RETURN to encode the plan ID on Bitcoin
We can use the inputs to distinguih identical-output plans without issue.
* Update OP_RETURN data access
It's not required to be the last output.
* Add Eventualities to Monero
An Eventuality is an effective equivalent to a SignableTransaction. That is
declared not by the inputs it spends, yet the outputs it creates.
Eventualities are also bound to a 32-byte RNG seed, enabling usage of a
hash-based identifier in a SignableTransaction, allowing multiple
SignableTransactions with the same output set to have different Eventualities.
In order to prevent triggering the burning bug, the RNG seed is hashed with
the planned-to-be-used inputs' output keys. While this does bind to them, it's
only loosely bound. The TX actually created may use different inputs entirely
if a forgery is crafted (which requires no brute forcing).
Binding to the key images would provide a strong binding, yet would require
knowing the key images, which requires active communication with the spend
key.
The purpose of this is so a multisig can identify if a Transaction the entire
group planned has been executed by a subset of the group or not. Once a plan
is created, it can have an Eventuality made. The Eventuality's extra is able
to be inserted into a HashMap, so all new on-chain transactions can be
trivially checked as potential candidates. Once a potential candidate is found,
a check involving ECC ops can be performed.
While this is arguably a DoS vector, the underlying Monero blockchain would
need to be spammed with transactions to trigger it. Accordingly, it becomes
a Monero blockchain DoS vector, when this code is written on the premise
of the Monero blockchain functioning. Accordingly, it is considered handled.
If a forgery does match, it must have created the exact same outputs the
multisig would've. Accordingly, it's argued the multisig shouldn't mind.
This entire suite of code is only necessary due to the lack of outgoing
view keys, yet it's able to avoid an interactive protocol to communicate
key images on every single received output.
While this could be locked to the multisig feature, there's no practical
benefit to doing so.
* Add support for encoding Monero address to instructions
* Move Serai's Monero address encoding into serai-client
serai-client is meant to be a single library enabling using Serai. While it was
originally written as an RPC client for Serai, apps actually using Serai will
primarily be sending transactions on connected networks. Sending those
transactions require proper {In, Out}Instructions, including proper address
encoding.
Not only has address encoding been moved, yet the subxt client is now behind
a feature. coin integrations have their own features, which are on by default.
primitives are always exposed.
* Reorganize file layout a bit, add feature flags to processor
* Tidy up ETH Dockerfile
* Add Bitcoin address encoding
* Move Bitcoin::Address to serai-client's
* Comment where tweaking needs to happen
* Add an API to check if a plan was completed in a specific TX
This allows any participating signer to submit the TX ID to prevent further
signing attempts.
Also performs some API cleanup.
* Minimize FROST dependencies
* Use a seeded RNG for key gen
* Tweak keys from Key gen
* Test proper usage of Branch/Change addresses
Adds a more descriptive error to an error case in decoys, and pads Monero
payments as needed.
* Also test spending the change output
* Add queued_plans to the Scheduler
queued_plans is for payments to be issued when an amount appears, yet the
amount is currently pre-fee. One the output is actually created, the
Scheduler should be notified of the amount it was created with, moving from
queued_plans to plans under the actual amount.
Also tightens debug_asserts to asserts for invariants which may are at risk of
being exclusive to prod.
* Add missing tweak_keys call
* Correct decoy selection height handling
* Add a few log statements to the scheduler
* Simplify test's get_block_number
* Simplify, while making more robust, branch address handling in Scheduler
* Have fees deducted from payments
Corrects Monero's handling of fees when there's no change address.
Adds a DUST variable, as needed due to 1_00_000_000 not being enough to pay
its fee on Monero.
* Add comment to Monero
* Consolidate BTC/XMR prepare_send code
These aren't fully consolidated. We'd need a SignableTransaction trait for
that. This is a lot cleaner though.
* Ban integrated addresses
The reasoning why is accordingly documented.
* Tidy TODOs/dust handling
* Update README TODO
* Use a determinisitic protocol version in Monero
* Test rebuilt KeyGen machines function as expected
* Use a more robust KeyGen entropy system
* Add DB TXNs
Also load entropy from env
* Add a loop for processing messages from substrate
Allows detecting if we're behind, and if so, waiting to handle the message
* Set Monero MAX_INPUTS properly
The previous number was based on an old hard fork. With the ring size having
increased, transactions have since got larger.
* Distinguish TODOs into TODO and TODO2s
TODO2s are for after protonet
* Zeroize secret share repr in ThresholdCore write
* Work on Eventualities
Adds serialization and stops signing when an eventuality is proven.
* Use a more robust DB key schema
* Update to {k, p}256 0.12
* cargo +nightly clippy
* cargo update
* Slight message-box tweaks
* Update to recent Monero merge
* Add a Coordinator trait for communication with coordinator
* Remove KeyGenHandle for just KeyGen
While KeyGen previously accepted instructions over a channel, this breaks the
ack flow needed for coordinator communication. Now, KeyGen is the direct object
with a handle() function for messages.
Thankfully, this ended up being rather trivial for KeyGen as it has no
background tasks.
* Add a handle function to Signer
Enables determining when it's finished handling a CoordinatorMessage and
therefore creating an acknowledgement.
* Save transactions used to complete eventualities
* Use a more intelligent sleep in the signer
* Emit SignedTransaction with the first ID *we can still get from our node*
* Move Substrate message handling into the new coordinator recv loop
* Add handle function to Scanner
* Remove the plans timer
Enables ensuring the ordring on the handling of plans.
* Remove the outputs function which panicked if a precondition wasn't met
The new API only returns outputs upon satisfaction of the precondition.
* Convert SignerOrder::SignTransaction to a function
* Remove the key_gen object from sign_plans
* Refactor out get_fee/prepare_send into dedicated functions
* Save plans being signed to the DB
* Reload transactions being signed on boot
* Stop reloading TXs being signed (and report it to peers)
* Remove message-box from the processor branch
We don't use it here yet.
* cargo +nightly fmt
* Move back common/zalloc
* Update subxt to 0.27
* Zeroize ^1.5, not 1
* Update GitHub workflow
* Remove usage of SignId in completed
2023-03-17 02:59:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-core-hashing"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "9.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
Processor (#259)
* Initial work on a message box
* Finish message-box (untested)
* Expand documentation
* Embed the recipient in the signature challenge
Prevents a message from A -> B from being read as from A -> C.
* Update documentation by bifurcating sender/receiver
* Panic on receiving an invalid signature
If we've received an invalid signature in an authenticated system, a
service is malicious, critically faulty (equivalent to malicious), or
the message layer has been compromised (or is otherwise critically
faulty).
Please note a receiver who handles a message they shouldn't will trigger
this. That falls under being critically faulty.
* Documentation and helper methods
SecureMessage::new and SecureMessage::serialize.
Secure Debug for MessageBox.
* Have SecureMessage not be serialized by default
Allows passing around in-memory, if desired, and moves the error from
decrypt to new (which performs deserialization).
Decrypt no longer has an error since it panics if given an invalid
signature, due to this being intranet code.
* Explain and improve nonce handling
Includes a missing zeroize call.
* Rebase to latest develop
Updates to transcript 0.2.0.
* Add a test for the MessageBox
* Export PrivateKey and PublicKey
* Also test serialization
* Add a key_gen binary to message_box
* Have SecureMessage support Serde
* Add encrypt_to_bytes and decrypt_from_bytes
* Support String ser via base64
* Rename encrypt/decrypt to encrypt_bytes/decrypt_to_bytes
* Directly operate with values supporting Borsh
* Use bincode instead of Borsh
By staying inside of serde, we'll support many more structs. While
bincode isn't canonical, we don't need canonicity on an authenticated,
internal system.
* Turn PrivateKey, PublicKey into structs
Uses Zeroizing for the PrivateKey per #150.
* from_string functions intended for loading from an env
* Use &str for PublicKey from_string (now from_str)
The PrivateKey takes the String to take ownership of its memory and
zeroize it. That isn't needed with PublicKeys.
* Finish updating from develop
* Resolve warning
* Use ZeroizingAlloc on the key_gen binary
* Move message-box from crypto/ to common/
* Move key serialization functions to ser
* add/remove functions in MessageBox
* Implement Hash on dalek_ff_group Points
* Make MessageBox generic to its key
Exposes a &'static str variant for internal use and a RistrettoPoint
variant for external use.
* Add Private to_string as deprecated
Stub before more competent tooling is deployed.
* Private to_public
* Test both Internal and External MessageBox, only use PublicKey in the pub API
* Remove panics on invalid signatures
Leftover from when this was solely internal which is now unsafe.
* Chicken scratch a Scanner task
* Add a write function to the DKG library
Enables writing directly to a file.
Also modifies serialize to return Zeroizing<Vec<u8>> instead of just Vec<u8>.
* Make dkg::encryption pub
* Remove encryption from MessageBox
* Use a 64-bit block number in Substrate
We use a 64-bit block number in general since u32 only works for 120 years
(with a 1 second block time). As some chains even push the 1 second threshold,
especially ones based on DAG consensus, this becomes potentially as low as 60
years.
While that should still be plenty, it's not worth wondering/debating. Since
Serai uses 64-bit block numbers elsewhere, this ensures consistency.
* Misc crypto lints
* Get the scanner scratch to compile
* Initial scanner test
* First few lines of scheduler
* Further work on scheduler, solidify API
* Define Scheduler TX format
* Branch creation algorithm
* Document when the branch algorithm isn't perfect
* Only scanned confirmed blocks
* Document Coin
* Remove Canonical/ChainNumber from processor
The processor should be abstracted from canonical numbers thanks to the
coordinator, making this unnecessary.
* Add README documenting processor flow
* Use Zeroize on substrate primitives
* Define messages from/to the processor
* Correct over-specified versioning
* Correct build re: in_instructions::primitives
* Debug/some serde in crypto/
* Use a struct for ValidatorSetInstance
* Add a processor key_gen task
Redos DB handling code.
* Replace trait + impl with wrapper struct
* Add a key confirmation flow to the key gen task
* Document concerns on key_gen
* Start on a signer task
* Add Send to FROST traits
* Move processor lib.rs to main.rs
Adds a dummy main to reduce clippy dead_code warnings.
* Further flesh out main.rs
* Move the DB trait to AsRef<[u8]>
* Signer task
* Remove a panic in bitcoin when there's insufficient funds
Unchecked underflow.
* Have Monero's mine_block mine one block, not 10
It was initially a nicety to deal with the 10 block lock. C::CONFIRMATIONS
should be used for that instead.
* Test signer
* Replace channel expects with log statements
The expects weren't problematic and had nicer code. They just clutter test
output.
* Remove the old wallet file
It predates the coordinator design and shouldn't be used.
* Rename tests/scan.rs to tests/scanner.rs
* Add a wallet test
Complements the recently removed wallet file by adding a test for the scanner,
scheduler, and signer together.
* Work on a run function
Triggers a clippy ICE.
* Resolve clippy ICE
The issue was the non-fully specified lambda in signer.
* Add KeyGenEvent and KeyGenOrder
Needed so we get KeyConfirmed messages from the key gen task.
While we could've read the CoordinatorMessage to see that, routing through the
key gen tasks ensures we only handle it once it's been successfully saved to
disk.
* Expand scanner test
* Clarify processor documentation
* Have the Scanner load keys on boot/save outputs to disk
* Use Vec<u8> for Block ID
Much more flexible.
* Panic if we see the same output multiple times
* Have the Scanner DB mark itself as corrupt when doing a multi-put
This REALLY should be a TX. Since we don't have a TX API right now, this at
least offers detection.
* Have DST'd DB keys accept AsRef<[u8]>
* Restore polling all signers
Writes a custom future to do so.
Also loads signers on boot using what the scanner claims are active keys.
* Schedule OutInstructions
Adds a data field to Payment.
Also cleans some dead code.
* Panic if we create an invalid transaction
Saves the TX once it's successfully signed so if we do panic, we have a copy.
* Route coordinator messages to their respective signer
Requires adding key to the SignId.
* Send SignTransaction orders for all plans
* Add a timer to retry sign_plans when prepare_send fails
* Minor fmt'ing
* Basic Fee API
* Move the change key into Plan
* Properly route activation_number
* Remove ScannerEvent::Block
It's not used under current designs
* Nicen logs
* Add utilities to get a block's number
* Have main issue AckBlock
Also has a few misc lints.
* Parse instructions out of outputs
* Tweak TODOs and remove an unwrap
* Update Bitcoin max input/output quantity
* Only read one piece of data from Monero
Due to output randomization, it's infeasible.
* Embed plan IDs into the TXs they create
We need to stop attempting signing if we've already signed a protocol. Ideally,
any one of the participating signers should be able to provide a proof the TX
was successfully signed. We can't just run a second signing protocol though as
a single malicious signer could complete the TX signature, and publish it,
yet not complete the secondary signature.
The TX itself has to be sufficient to show that the TX matches the plan. This
is done by embedding the ID, so matching addresses/amounts plans are
distinguished, and by allowing verification a TX actually matches a set of
addresses/amounts.
For Monero, this will need augmenting with the ephemeral keys (or usage of a
static seed for them).
* Don't use OP_RETURN to encode the plan ID on Bitcoin
We can use the inputs to distinguih identical-output plans without issue.
* Update OP_RETURN data access
It's not required to be the last output.
* Add Eventualities to Monero
An Eventuality is an effective equivalent to a SignableTransaction. That is
declared not by the inputs it spends, yet the outputs it creates.
Eventualities are also bound to a 32-byte RNG seed, enabling usage of a
hash-based identifier in a SignableTransaction, allowing multiple
SignableTransactions with the same output set to have different Eventualities.
In order to prevent triggering the burning bug, the RNG seed is hashed with
the planned-to-be-used inputs' output keys. While this does bind to them, it's
only loosely bound. The TX actually created may use different inputs entirely
if a forgery is crafted (which requires no brute forcing).
Binding to the key images would provide a strong binding, yet would require
knowing the key images, which requires active communication with the spend
key.
The purpose of this is so a multisig can identify if a Transaction the entire
group planned has been executed by a subset of the group or not. Once a plan
is created, it can have an Eventuality made. The Eventuality's extra is able
to be inserted into a HashMap, so all new on-chain transactions can be
trivially checked as potential candidates. Once a potential candidate is found,
a check involving ECC ops can be performed.
While this is arguably a DoS vector, the underlying Monero blockchain would
need to be spammed with transactions to trigger it. Accordingly, it becomes
a Monero blockchain DoS vector, when this code is written on the premise
of the Monero blockchain functioning. Accordingly, it is considered handled.
If a forgery does match, it must have created the exact same outputs the
multisig would've. Accordingly, it's argued the multisig shouldn't mind.
This entire suite of code is only necessary due to the lack of outgoing
view keys, yet it's able to avoid an interactive protocol to communicate
key images on every single received output.
While this could be locked to the multisig feature, there's no practical
benefit to doing so.
* Add support for encoding Monero address to instructions
* Move Serai's Monero address encoding into serai-client
serai-client is meant to be a single library enabling using Serai. While it was
originally written as an RPC client for Serai, apps actually using Serai will
primarily be sending transactions on connected networks. Sending those
transactions require proper {In, Out}Instructions, including proper address
encoding.
Not only has address encoding been moved, yet the subxt client is now behind
a feature. coin integrations have their own features, which are on by default.
primitives are always exposed.
* Reorganize file layout a bit, add feature flags to processor
* Tidy up ETH Dockerfile
* Add Bitcoin address encoding
* Move Bitcoin::Address to serai-client's
* Comment where tweaking needs to happen
* Add an API to check if a plan was completed in a specific TX
This allows any participating signer to submit the TX ID to prevent further
signing attempts.
Also performs some API cleanup.
* Minimize FROST dependencies
* Use a seeded RNG for key gen
* Tweak keys from Key gen
* Test proper usage of Branch/Change addresses
Adds a more descriptive error to an error case in decoys, and pads Monero
payments as needed.
* Also test spending the change output
* Add queued_plans to the Scheduler
queued_plans is for payments to be issued when an amount appears, yet the
amount is currently pre-fee. One the output is actually created, the
Scheduler should be notified of the amount it was created with, moving from
queued_plans to plans under the actual amount.
Also tightens debug_asserts to asserts for invariants which may are at risk of
being exclusive to prod.
* Add missing tweak_keys call
* Correct decoy selection height handling
* Add a few log statements to the scheduler
* Simplify test's get_block_number
* Simplify, while making more robust, branch address handling in Scheduler
* Have fees deducted from payments
Corrects Monero's handling of fees when there's no change address.
Adds a DUST variable, as needed due to 1_00_000_000 not being enough to pay
its fee on Monero.
* Add comment to Monero
* Consolidate BTC/XMR prepare_send code
These aren't fully consolidated. We'd need a SignableTransaction trait for
that. This is a lot cleaner though.
* Ban integrated addresses
The reasoning why is accordingly documented.
* Tidy TODOs/dust handling
* Update README TODO
* Use a determinisitic protocol version in Monero
* Test rebuilt KeyGen machines function as expected
* Use a more robust KeyGen entropy system
* Add DB TXNs
Also load entropy from env
* Add a loop for processing messages from substrate
Allows detecting if we're behind, and if so, waiting to handle the message
* Set Monero MAX_INPUTS properly
The previous number was based on an old hard fork. With the ring size having
increased, transactions have since got larger.
* Distinguish TODOs into TODO and TODO2s
TODO2s are for after protonet
* Zeroize secret share repr in ThresholdCore write
* Work on Eventualities
Adds serialization and stops signing when an eventuality is proven.
* Use a more robust DB key schema
* Update to {k, p}256 0.12
* cargo +nightly clippy
* cargo update
* Slight message-box tweaks
* Update to recent Monero merge
* Add a Coordinator trait for communication with coordinator
* Remove KeyGenHandle for just KeyGen
While KeyGen previously accepted instructions over a channel, this breaks the
ack flow needed for coordinator communication. Now, KeyGen is the direct object
with a handle() function for messages.
Thankfully, this ended up being rather trivial for KeyGen as it has no
background tasks.
* Add a handle function to Signer
Enables determining when it's finished handling a CoordinatorMessage and
therefore creating an acknowledgement.
* Save transactions used to complete eventualities
* Use a more intelligent sleep in the signer
* Emit SignedTransaction with the first ID *we can still get from our node*
* Move Substrate message handling into the new coordinator recv loop
* Add handle function to Scanner
* Remove the plans timer
Enables ensuring the ordring on the handling of plans.
* Remove the outputs function which panicked if a precondition wasn't met
The new API only returns outputs upon satisfaction of the precondition.
* Convert SignerOrder::SignTransaction to a function
* Remove the key_gen object from sign_plans
* Refactor out get_fee/prepare_send into dedicated functions
* Save plans being signed to the DB
* Reload transactions being signed on boot
* Stop reloading TXs being signed (and report it to peers)
* Remove message-box from the processor branch
We don't use it here yet.
* cargo +nightly fmt
* Move back common/zalloc
* Update subxt to 0.27
* Zeroize ^1.5, not 1
* Update GitHub workflow
* Remove usage of SignId in completed
2023-03-17 02:59:40 +00:00
|
|
|
dependencies = [
|
2023-04-15 09:23:57 +00:00
|
|
|
"blake2b_simd",
|
Processor (#259)
* Initial work on a message box
* Finish message-box (untested)
* Expand documentation
* Embed the recipient in the signature challenge
Prevents a message from A -> B from being read as from A -> C.
* Update documentation by bifurcating sender/receiver
* Panic on receiving an invalid signature
If we've received an invalid signature in an authenticated system, a
service is malicious, critically faulty (equivalent to malicious), or
the message layer has been compromised (or is otherwise critically
faulty).
Please note a receiver who handles a message they shouldn't will trigger
this. That falls under being critically faulty.
* Documentation and helper methods
SecureMessage::new and SecureMessage::serialize.
Secure Debug for MessageBox.
* Have SecureMessage not be serialized by default
Allows passing around in-memory, if desired, and moves the error from
decrypt to new (which performs deserialization).
Decrypt no longer has an error since it panics if given an invalid
signature, due to this being intranet code.
* Explain and improve nonce handling
Includes a missing zeroize call.
* Rebase to latest develop
Updates to transcript 0.2.0.
* Add a test for the MessageBox
* Export PrivateKey and PublicKey
* Also test serialization
* Add a key_gen binary to message_box
* Have SecureMessage support Serde
* Add encrypt_to_bytes and decrypt_from_bytes
* Support String ser via base64
* Rename encrypt/decrypt to encrypt_bytes/decrypt_to_bytes
* Directly operate with values supporting Borsh
* Use bincode instead of Borsh
By staying inside of serde, we'll support many more structs. While
bincode isn't canonical, we don't need canonicity on an authenticated,
internal system.
* Turn PrivateKey, PublicKey into structs
Uses Zeroizing for the PrivateKey per #150.
* from_string functions intended for loading from an env
* Use &str for PublicKey from_string (now from_str)
The PrivateKey takes the String to take ownership of its memory and
zeroize it. That isn't needed with PublicKeys.
* Finish updating from develop
* Resolve warning
* Use ZeroizingAlloc on the key_gen binary
* Move message-box from crypto/ to common/
* Move key serialization functions to ser
* add/remove functions in MessageBox
* Implement Hash on dalek_ff_group Points
* Make MessageBox generic to its key
Exposes a &'static str variant for internal use and a RistrettoPoint
variant for external use.
* Add Private to_string as deprecated
Stub before more competent tooling is deployed.
* Private to_public
* Test both Internal and External MessageBox, only use PublicKey in the pub API
* Remove panics on invalid signatures
Leftover from when this was solely internal which is now unsafe.
* Chicken scratch a Scanner task
* Add a write function to the DKG library
Enables writing directly to a file.
Also modifies serialize to return Zeroizing<Vec<u8>> instead of just Vec<u8>.
* Make dkg::encryption pub
* Remove encryption from MessageBox
* Use a 64-bit block number in Substrate
We use a 64-bit block number in general since u32 only works for 120 years
(with a 1 second block time). As some chains even push the 1 second threshold,
especially ones based on DAG consensus, this becomes potentially as low as 60
years.
While that should still be plenty, it's not worth wondering/debating. Since
Serai uses 64-bit block numbers elsewhere, this ensures consistency.
* Misc crypto lints
* Get the scanner scratch to compile
* Initial scanner test
* First few lines of scheduler
* Further work on scheduler, solidify API
* Define Scheduler TX format
* Branch creation algorithm
* Document when the branch algorithm isn't perfect
* Only scanned confirmed blocks
* Document Coin
* Remove Canonical/ChainNumber from processor
The processor should be abstracted from canonical numbers thanks to the
coordinator, making this unnecessary.
* Add README documenting processor flow
* Use Zeroize on substrate primitives
* Define messages from/to the processor
* Correct over-specified versioning
* Correct build re: in_instructions::primitives
* Debug/some serde in crypto/
* Use a struct for ValidatorSetInstance
* Add a processor key_gen task
Redos DB handling code.
* Replace trait + impl with wrapper struct
* Add a key confirmation flow to the key gen task
* Document concerns on key_gen
* Start on a signer task
* Add Send to FROST traits
* Move processor lib.rs to main.rs
Adds a dummy main to reduce clippy dead_code warnings.
* Further flesh out main.rs
* Move the DB trait to AsRef<[u8]>
* Signer task
* Remove a panic in bitcoin when there's insufficient funds
Unchecked underflow.
* Have Monero's mine_block mine one block, not 10
It was initially a nicety to deal with the 10 block lock. C::CONFIRMATIONS
should be used for that instead.
* Test signer
* Replace channel expects with log statements
The expects weren't problematic and had nicer code. They just clutter test
output.
* Remove the old wallet file
It predates the coordinator design and shouldn't be used.
* Rename tests/scan.rs to tests/scanner.rs
* Add a wallet test
Complements the recently removed wallet file by adding a test for the scanner,
scheduler, and signer together.
* Work on a run function
Triggers a clippy ICE.
* Resolve clippy ICE
The issue was the non-fully specified lambda in signer.
* Add KeyGenEvent and KeyGenOrder
Needed so we get KeyConfirmed messages from the key gen task.
While we could've read the CoordinatorMessage to see that, routing through the
key gen tasks ensures we only handle it once it's been successfully saved to
disk.
* Expand scanner test
* Clarify processor documentation
* Have the Scanner load keys on boot/save outputs to disk
* Use Vec<u8> for Block ID
Much more flexible.
* Panic if we see the same output multiple times
* Have the Scanner DB mark itself as corrupt when doing a multi-put
This REALLY should be a TX. Since we don't have a TX API right now, this at
least offers detection.
* Have DST'd DB keys accept AsRef<[u8]>
* Restore polling all signers
Writes a custom future to do so.
Also loads signers on boot using what the scanner claims are active keys.
* Schedule OutInstructions
Adds a data field to Payment.
Also cleans some dead code.
* Panic if we create an invalid transaction
Saves the TX once it's successfully signed so if we do panic, we have a copy.
* Route coordinator messages to their respective signer
Requires adding key to the SignId.
* Send SignTransaction orders for all plans
* Add a timer to retry sign_plans when prepare_send fails
* Minor fmt'ing
* Basic Fee API
* Move the change key into Plan
* Properly route activation_number
* Remove ScannerEvent::Block
It's not used under current designs
* Nicen logs
* Add utilities to get a block's number
* Have main issue AckBlock
Also has a few misc lints.
* Parse instructions out of outputs
* Tweak TODOs and remove an unwrap
* Update Bitcoin max input/output quantity
* Only read one piece of data from Monero
Due to output randomization, it's infeasible.
* Embed plan IDs into the TXs they create
We need to stop attempting signing if we've already signed a protocol. Ideally,
any one of the participating signers should be able to provide a proof the TX
was successfully signed. We can't just run a second signing protocol though as
a single malicious signer could complete the TX signature, and publish it,
yet not complete the secondary signature.
The TX itself has to be sufficient to show that the TX matches the plan. This
is done by embedding the ID, so matching addresses/amounts plans are
distinguished, and by allowing verification a TX actually matches a set of
addresses/amounts.
For Monero, this will need augmenting with the ephemeral keys (or usage of a
static seed for them).
* Don't use OP_RETURN to encode the plan ID on Bitcoin
We can use the inputs to distinguih identical-output plans without issue.
* Update OP_RETURN data access
It's not required to be the last output.
* Add Eventualities to Monero
An Eventuality is an effective equivalent to a SignableTransaction. That is
declared not by the inputs it spends, yet the outputs it creates.
Eventualities are also bound to a 32-byte RNG seed, enabling usage of a
hash-based identifier in a SignableTransaction, allowing multiple
SignableTransactions with the same output set to have different Eventualities.
In order to prevent triggering the burning bug, the RNG seed is hashed with
the planned-to-be-used inputs' output keys. While this does bind to them, it's
only loosely bound. The TX actually created may use different inputs entirely
if a forgery is crafted (which requires no brute forcing).
Binding to the key images would provide a strong binding, yet would require
knowing the key images, which requires active communication with the spend
key.
The purpose of this is so a multisig can identify if a Transaction the entire
group planned has been executed by a subset of the group or not. Once a plan
is created, it can have an Eventuality made. The Eventuality's extra is able
to be inserted into a HashMap, so all new on-chain transactions can be
trivially checked as potential candidates. Once a potential candidate is found,
a check involving ECC ops can be performed.
While this is arguably a DoS vector, the underlying Monero blockchain would
need to be spammed with transactions to trigger it. Accordingly, it becomes
a Monero blockchain DoS vector, when this code is written on the premise
of the Monero blockchain functioning. Accordingly, it is considered handled.
If a forgery does match, it must have created the exact same outputs the
multisig would've. Accordingly, it's argued the multisig shouldn't mind.
This entire suite of code is only necessary due to the lack of outgoing
view keys, yet it's able to avoid an interactive protocol to communicate
key images on every single received output.
While this could be locked to the multisig feature, there's no practical
benefit to doing so.
* Add support for encoding Monero address to instructions
* Move Serai's Monero address encoding into serai-client
serai-client is meant to be a single library enabling using Serai. While it was
originally written as an RPC client for Serai, apps actually using Serai will
primarily be sending transactions on connected networks. Sending those
transactions require proper {In, Out}Instructions, including proper address
encoding.
Not only has address encoding been moved, yet the subxt client is now behind
a feature. coin integrations have their own features, which are on by default.
primitives are always exposed.
* Reorganize file layout a bit, add feature flags to processor
* Tidy up ETH Dockerfile
* Add Bitcoin address encoding
* Move Bitcoin::Address to serai-client's
* Comment where tweaking needs to happen
* Add an API to check if a plan was completed in a specific TX
This allows any participating signer to submit the TX ID to prevent further
signing attempts.
Also performs some API cleanup.
* Minimize FROST dependencies
* Use a seeded RNG for key gen
* Tweak keys from Key gen
* Test proper usage of Branch/Change addresses
Adds a more descriptive error to an error case in decoys, and pads Monero
payments as needed.
* Also test spending the change output
* Add queued_plans to the Scheduler
queued_plans is for payments to be issued when an amount appears, yet the
amount is currently pre-fee. One the output is actually created, the
Scheduler should be notified of the amount it was created with, moving from
queued_plans to plans under the actual amount.
Also tightens debug_asserts to asserts for invariants which may are at risk of
being exclusive to prod.
* Add missing tweak_keys call
* Correct decoy selection height handling
* Add a few log statements to the scheduler
* Simplify test's get_block_number
* Simplify, while making more robust, branch address handling in Scheduler
* Have fees deducted from payments
Corrects Monero's handling of fees when there's no change address.
Adds a DUST variable, as needed due to 1_00_000_000 not being enough to pay
its fee on Monero.
* Add comment to Monero
* Consolidate BTC/XMR prepare_send code
These aren't fully consolidated. We'd need a SignableTransaction trait for
that. This is a lot cleaner though.
* Ban integrated addresses
The reasoning why is accordingly documented.
* Tidy TODOs/dust handling
* Update README TODO
* Use a determinisitic protocol version in Monero
* Test rebuilt KeyGen machines function as expected
* Use a more robust KeyGen entropy system
* Add DB TXNs
Also load entropy from env
* Add a loop for processing messages from substrate
Allows detecting if we're behind, and if so, waiting to handle the message
* Set Monero MAX_INPUTS properly
The previous number was based on an old hard fork. With the ring size having
increased, transactions have since got larger.
* Distinguish TODOs into TODO and TODO2s
TODO2s are for after protonet
* Zeroize secret share repr in ThresholdCore write
* Work on Eventualities
Adds serialization and stops signing when an eventuality is proven.
* Use a more robust DB key schema
* Update to {k, p}256 0.12
* cargo +nightly clippy
* cargo update
* Slight message-box tweaks
* Update to recent Monero merge
* Add a Coordinator trait for communication with coordinator
* Remove KeyGenHandle for just KeyGen
While KeyGen previously accepted instructions over a channel, this breaks the
ack flow needed for coordinator communication. Now, KeyGen is the direct object
with a handle() function for messages.
Thankfully, this ended up being rather trivial for KeyGen as it has no
background tasks.
* Add a handle function to Signer
Enables determining when it's finished handling a CoordinatorMessage and
therefore creating an acknowledgement.
* Save transactions used to complete eventualities
* Use a more intelligent sleep in the signer
* Emit SignedTransaction with the first ID *we can still get from our node*
* Move Substrate message handling into the new coordinator recv loop
* Add handle function to Scanner
* Remove the plans timer
Enables ensuring the ordring on the handling of plans.
* Remove the outputs function which panicked if a precondition wasn't met
The new API only returns outputs upon satisfaction of the precondition.
* Convert SignerOrder::SignTransaction to a function
* Remove the key_gen object from sign_plans
* Refactor out get_fee/prepare_send into dedicated functions
* Save plans being signed to the DB
* Reload transactions being signed on boot
* Stop reloading TXs being signed (and report it to peers)
* Remove message-box from the processor branch
We don't use it here yet.
* cargo +nightly fmt
* Move back common/zalloc
* Update subxt to 0.27
* Zeroize ^1.5, not 1
* Update GitHub workflow
* Remove usage of SignId in completed
2023-03-17 02:59:40 +00:00
|
|
|
"byteorder",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
Processor (#259)
* Initial work on a message box
* Finish message-box (untested)
* Expand documentation
* Embed the recipient in the signature challenge
Prevents a message from A -> B from being read as from A -> C.
* Update documentation by bifurcating sender/receiver
* Panic on receiving an invalid signature
If we've received an invalid signature in an authenticated system, a
service is malicious, critically faulty (equivalent to malicious), or
the message layer has been compromised (or is otherwise critically
faulty).
Please note a receiver who handles a message they shouldn't will trigger
this. That falls under being critically faulty.
* Documentation and helper methods
SecureMessage::new and SecureMessage::serialize.
Secure Debug for MessageBox.
* Have SecureMessage not be serialized by default
Allows passing around in-memory, if desired, and moves the error from
decrypt to new (which performs deserialization).
Decrypt no longer has an error since it panics if given an invalid
signature, due to this being intranet code.
* Explain and improve nonce handling
Includes a missing zeroize call.
* Rebase to latest develop
Updates to transcript 0.2.0.
* Add a test for the MessageBox
* Export PrivateKey and PublicKey
* Also test serialization
* Add a key_gen binary to message_box
* Have SecureMessage support Serde
* Add encrypt_to_bytes and decrypt_from_bytes
* Support String ser via base64
* Rename encrypt/decrypt to encrypt_bytes/decrypt_to_bytes
* Directly operate with values supporting Borsh
* Use bincode instead of Borsh
By staying inside of serde, we'll support many more structs. While
bincode isn't canonical, we don't need canonicity on an authenticated,
internal system.
* Turn PrivateKey, PublicKey into structs
Uses Zeroizing for the PrivateKey per #150.
* from_string functions intended for loading from an env
* Use &str for PublicKey from_string (now from_str)
The PrivateKey takes the String to take ownership of its memory and
zeroize it. That isn't needed with PublicKeys.
* Finish updating from develop
* Resolve warning
* Use ZeroizingAlloc on the key_gen binary
* Move message-box from crypto/ to common/
* Move key serialization functions to ser
* add/remove functions in MessageBox
* Implement Hash on dalek_ff_group Points
* Make MessageBox generic to its key
Exposes a &'static str variant for internal use and a RistrettoPoint
variant for external use.
* Add Private to_string as deprecated
Stub before more competent tooling is deployed.
* Private to_public
* Test both Internal and External MessageBox, only use PublicKey in the pub API
* Remove panics on invalid signatures
Leftover from when this was solely internal which is now unsafe.
* Chicken scratch a Scanner task
* Add a write function to the DKG library
Enables writing directly to a file.
Also modifies serialize to return Zeroizing<Vec<u8>> instead of just Vec<u8>.
* Make dkg::encryption pub
* Remove encryption from MessageBox
* Use a 64-bit block number in Substrate
We use a 64-bit block number in general since u32 only works for 120 years
(with a 1 second block time). As some chains even push the 1 second threshold,
especially ones based on DAG consensus, this becomes potentially as low as 60
years.
While that should still be plenty, it's not worth wondering/debating. Since
Serai uses 64-bit block numbers elsewhere, this ensures consistency.
* Misc crypto lints
* Get the scanner scratch to compile
* Initial scanner test
* First few lines of scheduler
* Further work on scheduler, solidify API
* Define Scheduler TX format
* Branch creation algorithm
* Document when the branch algorithm isn't perfect
* Only scanned confirmed blocks
* Document Coin
* Remove Canonical/ChainNumber from processor
The processor should be abstracted from canonical numbers thanks to the
coordinator, making this unnecessary.
* Add README documenting processor flow
* Use Zeroize on substrate primitives
* Define messages from/to the processor
* Correct over-specified versioning
* Correct build re: in_instructions::primitives
* Debug/some serde in crypto/
* Use a struct for ValidatorSetInstance
* Add a processor key_gen task
Redos DB handling code.
* Replace trait + impl with wrapper struct
* Add a key confirmation flow to the key gen task
* Document concerns on key_gen
* Start on a signer task
* Add Send to FROST traits
* Move processor lib.rs to main.rs
Adds a dummy main to reduce clippy dead_code warnings.
* Further flesh out main.rs
* Move the DB trait to AsRef<[u8]>
* Signer task
* Remove a panic in bitcoin when there's insufficient funds
Unchecked underflow.
* Have Monero's mine_block mine one block, not 10
It was initially a nicety to deal with the 10 block lock. C::CONFIRMATIONS
should be used for that instead.
* Test signer
* Replace channel expects with log statements
The expects weren't problematic and had nicer code. They just clutter test
output.
* Remove the old wallet file
It predates the coordinator design and shouldn't be used.
* Rename tests/scan.rs to tests/scanner.rs
* Add a wallet test
Complements the recently removed wallet file by adding a test for the scanner,
scheduler, and signer together.
* Work on a run function
Triggers a clippy ICE.
* Resolve clippy ICE
The issue was the non-fully specified lambda in signer.
* Add KeyGenEvent and KeyGenOrder
Needed so we get KeyConfirmed messages from the key gen task.
While we could've read the CoordinatorMessage to see that, routing through the
key gen tasks ensures we only handle it once it's been successfully saved to
disk.
* Expand scanner test
* Clarify processor documentation
* Have the Scanner load keys on boot/save outputs to disk
* Use Vec<u8> for Block ID
Much more flexible.
* Panic if we see the same output multiple times
* Have the Scanner DB mark itself as corrupt when doing a multi-put
This REALLY should be a TX. Since we don't have a TX API right now, this at
least offers detection.
* Have DST'd DB keys accept AsRef<[u8]>
* Restore polling all signers
Writes a custom future to do so.
Also loads signers on boot using what the scanner claims are active keys.
* Schedule OutInstructions
Adds a data field to Payment.
Also cleans some dead code.
* Panic if we create an invalid transaction
Saves the TX once it's successfully signed so if we do panic, we have a copy.
* Route coordinator messages to their respective signer
Requires adding key to the SignId.
* Send SignTransaction orders for all plans
* Add a timer to retry sign_plans when prepare_send fails
* Minor fmt'ing
* Basic Fee API
* Move the change key into Plan
* Properly route activation_number
* Remove ScannerEvent::Block
It's not used under current designs
* Nicen logs
* Add utilities to get a block's number
* Have main issue AckBlock
Also has a few misc lints.
* Parse instructions out of outputs
* Tweak TODOs and remove an unwrap
* Update Bitcoin max input/output quantity
* Only read one piece of data from Monero
Due to output randomization, it's infeasible.
* Embed plan IDs into the TXs they create
We need to stop attempting signing if we've already signed a protocol. Ideally,
any one of the participating signers should be able to provide a proof the TX
was successfully signed. We can't just run a second signing protocol though as
a single malicious signer could complete the TX signature, and publish it,
yet not complete the secondary signature.
The TX itself has to be sufficient to show that the TX matches the plan. This
is done by embedding the ID, so matching addresses/amounts plans are
distinguished, and by allowing verification a TX actually matches a set of
addresses/amounts.
For Monero, this will need augmenting with the ephemeral keys (or usage of a
static seed for them).
* Don't use OP_RETURN to encode the plan ID on Bitcoin
We can use the inputs to distinguih identical-output plans without issue.
* Update OP_RETURN data access
It's not required to be the last output.
* Add Eventualities to Monero
An Eventuality is an effective equivalent to a SignableTransaction. That is
declared not by the inputs it spends, yet the outputs it creates.
Eventualities are also bound to a 32-byte RNG seed, enabling usage of a
hash-based identifier in a SignableTransaction, allowing multiple
SignableTransactions with the same output set to have different Eventualities.
In order to prevent triggering the burning bug, the RNG seed is hashed with
the planned-to-be-used inputs' output keys. While this does bind to them, it's
only loosely bound. The TX actually created may use different inputs entirely
if a forgery is crafted (which requires no brute forcing).
Binding to the key images would provide a strong binding, yet would require
knowing the key images, which requires active communication with the spend
key.
The purpose of this is so a multisig can identify if a Transaction the entire
group planned has been executed by a subset of the group or not. Once a plan
is created, it can have an Eventuality made. The Eventuality's extra is able
to be inserted into a HashMap, so all new on-chain transactions can be
trivially checked as potential candidates. Once a potential candidate is found,
a check involving ECC ops can be performed.
While this is arguably a DoS vector, the underlying Monero blockchain would
need to be spammed with transactions to trigger it. Accordingly, it becomes
a Monero blockchain DoS vector, when this code is written on the premise
of the Monero blockchain functioning. Accordingly, it is considered handled.
If a forgery does match, it must have created the exact same outputs the
multisig would've. Accordingly, it's argued the multisig shouldn't mind.
This entire suite of code is only necessary due to the lack of outgoing
view keys, yet it's able to avoid an interactive protocol to communicate
key images on every single received output.
While this could be locked to the multisig feature, there's no practical
benefit to doing so.
* Add support for encoding Monero address to instructions
* Move Serai's Monero address encoding into serai-client
serai-client is meant to be a single library enabling using Serai. While it was
originally written as an RPC client for Serai, apps actually using Serai will
primarily be sending transactions on connected networks. Sending those
transactions require proper {In, Out}Instructions, including proper address
encoding.
Not only has address encoding been moved, yet the subxt client is now behind
a feature. coin integrations have their own features, which are on by default.
primitives are always exposed.
* Reorganize file layout a bit, add feature flags to processor
* Tidy up ETH Dockerfile
* Add Bitcoin address encoding
* Move Bitcoin::Address to serai-client's
* Comment where tweaking needs to happen
* Add an API to check if a plan was completed in a specific TX
This allows any participating signer to submit the TX ID to prevent further
signing attempts.
Also performs some API cleanup.
* Minimize FROST dependencies
* Use a seeded RNG for key gen
* Tweak keys from Key gen
* Test proper usage of Branch/Change addresses
Adds a more descriptive error to an error case in decoys, and pads Monero
payments as needed.
* Also test spending the change output
* Add queued_plans to the Scheduler
queued_plans is for payments to be issued when an amount appears, yet the
amount is currently pre-fee. One the output is actually created, the
Scheduler should be notified of the amount it was created with, moving from
queued_plans to plans under the actual amount.
Also tightens debug_asserts to asserts for invariants which may are at risk of
being exclusive to prod.
* Add missing tweak_keys call
* Correct decoy selection height handling
* Add a few log statements to the scheduler
* Simplify test's get_block_number
* Simplify, while making more robust, branch address handling in Scheduler
* Have fees deducted from payments
Corrects Monero's handling of fees when there's no change address.
Adds a DUST variable, as needed due to 1_00_000_000 not being enough to pay
its fee on Monero.
* Add comment to Monero
* Consolidate BTC/XMR prepare_send code
These aren't fully consolidated. We'd need a SignableTransaction trait for
that. This is a lot cleaner though.
* Ban integrated addresses
The reasoning why is accordingly documented.
* Tidy TODOs/dust handling
* Update README TODO
* Use a determinisitic protocol version in Monero
* Test rebuilt KeyGen machines function as expected
* Use a more robust KeyGen entropy system
* Add DB TXNs
Also load entropy from env
* Add a loop for processing messages from substrate
Allows detecting if we're behind, and if so, waiting to handle the message
* Set Monero MAX_INPUTS properly
The previous number was based on an old hard fork. With the ring size having
increased, transactions have since got larger.
* Distinguish TODOs into TODO and TODO2s
TODO2s are for after protonet
* Zeroize secret share repr in ThresholdCore write
* Work on Eventualities
Adds serialization and stops signing when an eventuality is proven.
* Use a more robust DB key schema
* Update to {k, p}256 0.12
* cargo +nightly clippy
* cargo update
* Slight message-box tweaks
* Update to recent Monero merge
* Add a Coordinator trait for communication with coordinator
* Remove KeyGenHandle for just KeyGen
While KeyGen previously accepted instructions over a channel, this breaks the
ack flow needed for coordinator communication. Now, KeyGen is the direct object
with a handle() function for messages.
Thankfully, this ended up being rather trivial for KeyGen as it has no
background tasks.
* Add a handle function to Signer
Enables determining when it's finished handling a CoordinatorMessage and
therefore creating an acknowledgement.
* Save transactions used to complete eventualities
* Use a more intelligent sleep in the signer
* Emit SignedTransaction with the first ID *we can still get from our node*
* Move Substrate message handling into the new coordinator recv loop
* Add handle function to Scanner
* Remove the plans timer
Enables ensuring the ordring on the handling of plans.
* Remove the outputs function which panicked if a precondition wasn't met
The new API only returns outputs upon satisfaction of the precondition.
* Convert SignerOrder::SignTransaction to a function
* Remove the key_gen object from sign_plans
* Refactor out get_fee/prepare_send into dedicated functions
* Save plans being signed to the DB
* Reload transactions being signed on boot
* Stop reloading TXs being signed (and report it to peers)
* Remove message-box from the processor branch
We don't use it here yet.
* cargo +nightly fmt
* Move back common/zalloc
* Update subxt to 0.27
* Zeroize ^1.5, not 1
* Update GitHub workflow
* Remove usage of SignId in completed
2023-03-17 02:59:40 +00:00
|
|
|
"sha3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"twox-hash",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-core-hashing-proc-macro"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "9.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"quote",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-core-hashing",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-database"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"kvdb",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-debug-derive"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "8.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-externalities"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "0.19.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"environmental",
|
|
|
|
"parity-scale-codec",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-storage",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-inherents"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"parity-scale-codec",
|
2023-03-06 12:39:43 +00:00
|
|
|
"scale-info",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-io"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "23.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"bytes",
|
2023-08-25 03:55:47 +00:00
|
|
|
"ed25519",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2023-03-31 06:34:52 +00:00
|
|
|
"rustversion",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
|
|
|
"sp-externalities",
|
|
|
|
"sp-keystore",
|
|
|
|
"sp-runtime-interface",
|
|
|
|
"sp-state-machine",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-tracing",
|
|
|
|
"sp-trie",
|
|
|
|
"tracing",
|
|
|
|
"tracing-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-keyring"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "24.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"lazy_static",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
2023-07-28 03:38:04 +00:00
|
|
|
"strum 0.25.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-keystore"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "0.27.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
|
|
|
"sp-externalities",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-maybe-compressed-blob"
|
|
|
|
version = "4.1.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"thiserror",
|
2023-07-24 08:54:13 +00:00
|
|
|
"zstd 0.12.4",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-05-01 07:17:37 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-metadata-ir"
|
|
|
|
version = "0.1.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-05-01 07:17:37 +00:00
|
|
|
dependencies = [
|
2023-11-28 07:29:50 +00:00
|
|
|
"frame-metadata",
|
2023-05-01 07:17:37 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2023-05-01 07:17:37 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-offchain"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"sp-api",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-panic-handler"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "8.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"backtrace",
|
|
|
|
"lazy_static",
|
|
|
|
"regex",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-rpc"
|
|
|
|
version = "6.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"rustc-hash",
|
|
|
|
"serde",
|
|
|
|
"sp-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-runtime"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "24.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
|
|
|
"hash256-std-hasher",
|
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"paste",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-application-crypto",
|
|
|
|
"sp-arithmetic",
|
|
|
|
"sp-core",
|
|
|
|
"sp-io",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-weights",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-runtime-interface"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "17.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-09-29 18:33:09 +00:00
|
|
|
"bytes",
|
2022-07-16 21:49:35 +00:00
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"parity-scale-codec",
|
2022-12-07 23:05:06 +00:00
|
|
|
"primitive-types",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-externalities",
|
|
|
|
"sp-runtime-interface-proc-macro",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-storage",
|
|
|
|
"sp-tracing",
|
|
|
|
"sp-wasm-interface",
|
|
|
|
"static_assertions",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-runtime-interface-proc-macro"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "11.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
2023-11-25 09:01:11 +00:00
|
|
|
"proc-macro-crate 1.3.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-session"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"sp-api",
|
|
|
|
"sp-core",
|
2023-07-19 02:30:55 +00:00
|
|
|
"sp-keystore",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-runtime",
|
|
|
|
"sp-staking",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-staking"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-19 02:30:55 +00:00
|
|
|
"impl-trait-for-tuples",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
2023-05-01 07:17:37 +00:00
|
|
|
"serde",
|
2023-01-04 08:17:36 +00:00
|
|
|
"sp-core",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-state-machine"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "0.28.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"hash-db",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
|
|
|
"sp-externalities",
|
|
|
|
"sp-panic-handler",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-trie",
|
|
|
|
"thiserror",
|
|
|
|
"tracing",
|
2023-07-19 02:30:55 +00:00
|
|
|
"trie-db",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-07-19 02:30:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-std"
|
|
|
|
version = "8.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2023-07-19 02:30:55 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-storage"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "13.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-01-05 03:52:41 +00:00
|
|
|
"impl-serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
|
|
|
"ref-cast",
|
|
|
|
"serde",
|
|
|
|
"sp-debug-derive",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-timestamp"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sp-inherents",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-tracing"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "10.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tracing",
|
|
|
|
"tracing-core",
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
"tracing-subscriber 0.2.25",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-transaction-pool"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"sp-api",
|
|
|
|
"sp-runtime",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-trie"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "22.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-08-22 02:58:45 +00:00
|
|
|
"ahash",
|
2022-07-16 21:49:35 +00:00
|
|
|
"hash-db",
|
2024-05-21 10:09:04 +00:00
|
|
|
"hashbrown 0.14.5",
|
2022-09-29 18:33:09 +00:00
|
|
|
"lazy_static",
|
2022-07-16 21:49:35 +00:00
|
|
|
"memory-db",
|
2022-09-29 18:33:09 +00:00
|
|
|
"nohash-hasher",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"scale-info",
|
2023-03-06 12:39:43 +00:00
|
|
|
"schnellru",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-core",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
2022-09-29 18:33:09 +00:00
|
|
|
"tracing",
|
2022-07-16 21:49:35 +00:00
|
|
|
"trie-db",
|
|
|
|
"trie-root",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-version"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "22.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-01-05 03:52:41 +00:00
|
|
|
"impl-serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parity-scale-codec",
|
2022-11-11 04:59:20 +00:00
|
|
|
"parity-wasm",
|
2022-07-16 21:49:35 +00:00
|
|
|
"scale-info",
|
|
|
|
"serde",
|
|
|
|
"sp-core-hashing-proc-macro",
|
|
|
|
"sp-runtime",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-version-proc-macro",
|
|
|
|
"thiserror",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-version-proc-macro"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "8.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "sp-wasm-interface"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "14.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-03-06 12:39:43 +00:00
|
|
|
"anyhow",
|
2022-07-16 21:49:35 +00:00
|
|
|
"impl-trait-for-tuples",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasmtime",
|
|
|
|
]
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sp-weights"
|
2023-07-19 02:30:55 +00:00
|
|
|
version = "20.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
|
|
|
"parity-scale-codec",
|
|
|
|
"scale-info",
|
|
|
|
"serde",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-09-29 18:33:09 +00:00
|
|
|
"sp-arithmetic",
|
|
|
|
"sp-core",
|
|
|
|
"sp-debug-derive",
|
2023-07-19 03:01:51 +00:00
|
|
|
"sp-std",
|
2022-09-29 18:33:09 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "spin"
|
|
|
|
version = "0.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6e63cff320ae2c57904679ba7cb63280a3dc4613885beafb148ee7bf9aa9042d"
|
|
|
|
|
2023-06-29 01:16:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "spin"
|
|
|
|
version = "0.9.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6980e8d7511241f8acf4aebddbb1ff938df5eebe98691418c4468d0b72a96a67"
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "spki"
|
2023-12-03 05:04:59 +00:00
|
|
|
version = "0.7.3"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-03 05:04:59 +00:00
|
|
|
checksum = "d91ed6c858b01f942cd56b37a94b3e0a1798290327d1236e4d9cf4eaca44d29d"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"base64ct",
|
2023-07-28 03:38:04 +00:00
|
|
|
"der",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "sptr"
|
|
|
|
version = "0.3.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "3b9b39299b249ad65f3b7e96443bad61c02ca5cd3589f46cb6d610a0fd6c0d6a"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ss58-registry"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.50.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "43fce22ed1df64d04b262351c8f9d5c6da4f76f79f25ad15529792f893fad25d"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"Inflector",
|
|
|
|
"num-format",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"unicode-xid",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "stable_deref_trait"
|
|
|
|
version = "1.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a8f112729512f8e442d81f95a8a7ddf2b7c6b8a1a6f509a95864142b30cab2d3"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "static_assertions"
|
|
|
|
version = "1.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a2eb9349b6444b326872e140eb1cf5e7c522154d69e7a0ffb0fb81c06b37543f"
|
|
|
|
|
2022-09-29 18:33:09 +00:00
|
|
|
[[package]]
|
|
|
|
name = "static_init"
|
|
|
|
version = "1.0.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8a2a1c578e98c1c16fc3b8ec1328f7659a500737d7a0c6d625e73e830ff9c1f6"
|
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"bitflags 1.3.2",
|
2022-09-29 18:33:09 +00:00
|
|
|
"cfg_aliases",
|
|
|
|
"libc",
|
|
|
|
"parking_lot 0.11.2",
|
2022-12-21 04:12:26 +00:00
|
|
|
"parking_lot_core 0.8.6",
|
2022-09-29 18:33:09 +00:00
|
|
|
"static_init_macro",
|
|
|
|
"winapi",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "static_init_macro"
|
|
|
|
version = "1.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "70a2595fc3aa78f2d0e45dd425b22282dd863273761cc77780914b2cf3003acf"
|
|
|
|
dependencies = [
|
|
|
|
"cfg_aliases",
|
|
|
|
"memchr",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-09-29 18:33:09 +00:00
|
|
|
]
|
|
|
|
|
2023-04-22 08:38:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "std-shims"
|
2023-08-08 22:18:59 +00:00
|
|
|
version = "0.1.1"
|
2023-04-22 08:38:47 +00:00
|
|
|
dependencies = [
|
2024-05-21 10:09:04 +00:00
|
|
|
"hashbrown 0.14.5",
|
2023-06-29 01:16:33 +00:00
|
|
|
"spin 0.9.8",
|
2023-04-22 08:38:47 +00:00
|
|
|
]
|
|
|
|
|
2023-07-28 03:38:04 +00:00
|
|
|
[[package]]
|
|
|
|
name = "strobe-rs"
|
|
|
|
version = "0.8.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "fabb238a1cccccfa4c4fb703670c0d157e1256c1ba695abf1b93bd2bb14bab2d"
|
|
|
|
dependencies = [
|
|
|
|
"bitflags 1.3.2",
|
|
|
|
"byteorder",
|
|
|
|
"keccak",
|
|
|
|
"subtle",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "strsim"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "0.11.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "7da8b5736845d9f2fcb837ea5d9e2628564b3b043a70948a3f0b778838c5fb4f"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "strum"
|
|
|
|
version = "0.24.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "063e6045c0e62079840579a7e47a355ae92f60eb74daaf156fb1e84ba164e63f"
|
2023-07-19 02:30:55 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "strum"
|
|
|
|
version = "0.25.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "290d54ea6f91c969195bdbcd7442c8c2a2ba87da8bf60a7ee86a235d4bc1e125"
|
|
|
|
dependencies = [
|
2023-10-16 03:57:45 +00:00
|
|
|
"strum_macros 0.25.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2024-06-13 19:57:08 +00:00
|
|
|
[[package]]
|
|
|
|
name = "strum"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.26.3"
|
2024-06-13 19:57:08 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "8fec0f0aef304996cf250b31b5a10dee7980c85da9d759361292b8bca5a18f06"
|
2024-06-13 19:57:08 +00:00
|
|
|
dependencies = [
|
|
|
|
"strum_macros 0.26.4",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "strum_macros"
|
2022-08-16 07:44:32 +00:00
|
|
|
version = "0.24.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-08-16 07:44:32 +00:00
|
|
|
checksum = "1e385be0d24f186b4ce2f9982191e7101bb737312ad61c1f2f984f34bcf85d59"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.4.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"rustversion",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-07-19 02:30:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "strum_macros"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.25.3"
|
2023-07-19 02:30:55 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "23dc1fa9ac9c169a78ba62f0b841814b7abae11bdd047b9c58f893439e309ea0"
|
2023-07-19 02:30:55 +00:00
|
|
|
dependencies = [
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"heck 0.4.1",
|
2023-07-19 02:30:55 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"rustversion",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2024-06-13 19:57:08 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "strum_macros"
|
|
|
|
version = "0.26.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "4c6bee85a5a24955dc440386795aa378cd9cf82acd5f764469152d2270e581be"
|
|
|
|
dependencies = [
|
|
|
|
"heck 0.5.0",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"rustversion",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-07-19 02:30:55 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "substrate-bip39"
|
2023-11-06 12:19:55 +00:00
|
|
|
version = "0.4.5"
|
|
|
|
source = "git+https://github.com/serai-dex/substrate-bip39#efb58a5263b8585b2d0ef17ed3c989e1ca09294e"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-07-28 03:38:04 +00:00
|
|
|
"hmac",
|
2023-07-19 02:30:55 +00:00
|
|
|
"pbkdf2 0.12.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"schnorrkel",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "substrate-build-script-utils"
|
|
|
|
version = "3.0.0"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "substrate-frame-rpc-system"
|
|
|
|
version = "4.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"frame-system-rpc-runtime-api",
|
|
|
|
"futures",
|
|
|
|
"jsonrpsee",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
|
|
|
"sc-rpc-api",
|
|
|
|
"sc-transaction-pool-api",
|
|
|
|
"sp-api",
|
|
|
|
"sp-block-builder",
|
|
|
|
"sp-blockchain",
|
|
|
|
"sp-core",
|
|
|
|
"sp-runtime",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "substrate-prometheus-endpoint"
|
|
|
|
version = "0.10.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"hyper 0.14.30",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"prometheus",
|
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "substrate-wasm-builder"
|
|
|
|
version = "5.0.0-dev"
|
2024-01-17 00:32:30 +00:00
|
|
|
source = "git+https://github.com/serai-dex/substrate#6e3f07bf5c98a6a3ec15f2b1a46148aa8c7d737a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-04-15 07:27:45 +00:00
|
|
|
"anstyle",
|
2022-07-16 21:49:35 +00:00
|
|
|
"build-helper",
|
2023-03-06 12:39:43 +00:00
|
|
|
"cargo_metadata",
|
2022-07-16 21:49:35 +00:00
|
|
|
"filetime",
|
2023-07-19 02:30:55 +00:00
|
|
|
"parity-wasm",
|
2022-07-16 21:49:35 +00:00
|
|
|
"sp-maybe-compressed-blob",
|
2023-07-28 03:38:04 +00:00
|
|
|
"strum 0.25.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tempfile",
|
2023-09-12 11:47:03 +00:00
|
|
|
"toml 0.7.8",
|
2022-07-16 21:49:35 +00:00
|
|
|
"walkdir",
|
2022-11-11 04:59:20 +00:00
|
|
|
"wasm-opt",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "subtle"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "2.6.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "13c2bddecc57b384dee18652358fb23172facb8a2c51ccc10d74c157bdea3292"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "syn"
|
2023-03-06 12:39:43 +00:00
|
|
|
version = "1.0.109"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-06 12:39:43 +00:00
|
|
|
checksum = "72b64191b275b66ffe2469e8af2c1cfe3bafa67b529ead792a6d0160888b4237"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"unicode-ident",
|
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "syn"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "2.0.77"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "9f35bcdf61fd8e7be6caf75f429fdca8beb3ed76584befb503b1569faee373ed"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
|
|
|
"unicode-ident",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "syn-solidity"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.0"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "284c41c2919303438fcf8dede4036fd1e82d4fc0fbb2b279bd2a1442c909ca92"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
dependencies = [
|
|
|
|
"paste",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
]
|
|
|
|
|
2023-11-25 09:01:11 +00:00
|
|
|
[[package]]
|
|
|
|
name = "syn_derive"
|
|
|
|
version = "0.1.8"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1329189c02ff984e9736652b1631330da25eaa6bc639089ed4915d25446cbe7b"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro-error",
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-11-25 09:01:11 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "synstructure"
|
|
|
|
version = "0.12.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f36bdaa60a83aca3921b5259d5400cbf5e90fc51931376a9bd4a0eb79aa7210f"
|
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2023-03-25 04:45:33 +00:00
|
|
|
"syn 1.0.109",
|
2022-07-16 21:49:35 +00:00
|
|
|
"unicode-xid",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "system-configuration"
|
2023-06-22 10:25:30 +00:00
|
|
|
version = "0.5.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-22 10:25:30 +00:00
|
|
|
checksum = "ba3a3adc5c275d719af8cb4272ea1c4a6d668a777f37e115f6d11ddbc1c8e0e7"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"bitflags 1.3.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"core-foundation",
|
|
|
|
"system-configuration-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "system-configuration-sys"
|
|
|
|
version = "0.5.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a75fb188eb626b924683e3b95e3a48e63551fcfb51949de2f06a9d91dbee93c9"
|
|
|
|
dependencies = [
|
|
|
|
"core-foundation-sys",
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tap"
|
|
|
|
version = "1.0.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "55937e1799185b12863d447f42597ed69d9928686b8d88a1df17376a097d8369"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "target-lexicon"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.12.16"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "61c41af27dd6d1e27b1b16b489db798443478cef1f06a660c96db617ba5de3b1"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tempfile"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "3.11.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "b8fcd239983515c23a32fb82099f97d0b11b8c72f654ed659363a95c3dad7a53"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-11-22 06:24:17 +00:00
|
|
|
"fastrand",
|
2024-09-05 21:03:23 +00:00
|
|
|
"once_cell",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2023-12-30 07:36:51 +00:00
|
|
|
"windows-sys 0.52.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tendermint-machine"
|
2022-12-05 22:26:28 +00:00
|
|
|
version = "0.2.0"
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
2023-12-11 00:32:43 +00:00
|
|
|
"futures-channel",
|
|
|
|
"futures-util",
|
2023-08-08 19:12:47 +00:00
|
|
|
"hex",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
2024-09-05 20:30:27 +00:00
|
|
|
"patchable-async-sleep",
|
2024-03-08 03:40:04 +00:00
|
|
|
"serai-db",
|
Initial Tendermint implementation (#145)
* Machine without timeouts
* Time code
* Move substrate/consensus/tendermint to substrate/tendermint
* Delete the old paper doc
* Refactor out external parts to generics
Also creates a dedicated file for the message log.
* Refactor <V, B> to type V, type B
* Successfully compiling
* Calculate timeouts
* Fix test
* Finish timeouts
* Misc cleanup
* Define a signature scheme trait
* Implement serialization via parity's scale codec
Ideally, this would be generic. Unfortunately, the generic API serde
doesn't natively support borsh, nor SCALE, and while there is a serde
SCALE crate, it's old. While it may be complete, it's not worth working
with.
While we could still grab bincode, and a variety of other formats, it
wasn't worth it to go custom and for Serai, we'll be using SCALE almost
everywhere anyways.
* Implement usage of the signature scheme
* Make the infinite test non-infinite
* Provide a dedicated signature in Precommit of just the block hash
Greatly simplifies verifying when syncing.
* Dedicated Commit object
Restores sig aggregation API.
* Tidy README
* Document tendermint
* Sign the ID directly instead of its SCALE encoding
For a hash, which is fixed-size, these should be the same yet this helps
move past the dependency on SCALE. It also, for any type where the two
values are different, smooths integration.
* Litany of bug fixes
Also attempts to make the code more readable while updating/correcting
documentation.
* Remove async recursion
Greatly increases safety as well by ensuring only one message is
processed at once.
* Correct timing issues
1) Commit didn't include the round, leaving the clock in question.
2) Machines started with a local time, instead of a proper start time.
3) Machines immediately started the next block instead of waiting for
the block time.
* Replace MultiSignature with sr25519::Signature
* Minor SignatureScheme API changes
* Map TM SignatureScheme to Substrate's sr25519
* Initial work on an import queue
* Properly use check_block
* Rename import to import_queue
* Implement tendermint_machine::Block for Substrate Blocks
Unfortunately, this immediately makes Tendermint machine capable of
deployment as crate since it uses a git reference. In the future, a
Cargo.toml patch section for serai/substrate should be investigated.
This is being done regardless as it's the quickest way forward and this
is for Serai.
* Dummy Weights
* Move documentation to the top of the file
* Move logic into TendermintImport itself
Multiple traits exist to verify/handle blocks. I'm unsure exactly when
each will be called in the pipeline, so the easiest solution is to have
every step run every check.
That would be extremely computationally expensive if we ran EVERY check,
yet we rely on Substrate for execution (and according checks), which are
limited to just the actual import function.
Since we're calling this code from many places, it makes sense for it to
be consolidated under TendermintImport.
* BlockImport, JustificationImport, Verifier, and import_queue function
* Update consensus/lib.rs from PoW to Tendermint
Not possible to be used as the previous consensus could. It will not
produce blocks nor does it currenly even instantiate a machine. This is
just he next step.
* Update Cargo.tomls for substrate packages
* Tendermint SelectChain
This is incompatible with Substrate's expectations, yet should be valid
for ours
* Move the node over to the new SelectChain
* Minor tweaks
* Update SelectChain documentation
* Remove substrate/node lib.rs
This shouldn't be used as a library AFAIK. While runtime should be, and
arguably should even be published, I have yet to see node in the same
way. Helps tighten API boundaries.
* Remove unused macro_use
* Replace panicking todos with stubs and // TODO
Enables progress.
* Reduce chain_spec and use more accurate naming
* Implement block proposal logic
* Modularize to get_proposal
* Trigger block importing
Doesn't wait for the response yet, which it needs to.
* Get the result of block importing
* Split import_queue into a series of files
* Provide a way to create the machine
The BasicQueue returned obscures the TendermintImport struct.
Accordingly, a Future scoped with access is returned upwards, which when
awaited will create the machine. This makes creating the machine
optional while maintaining scope boundaries.
Is sufficient to create a 1-node net which produces and finalizes
blocks.
* Don't import justifications multiple times
Also don't broadcast blocks which were solely proposed.
* Correct justication import pipeline
Removes JustificationImport as it should never be used.
* Announce blocks
By claiming File, they're not sent ovber the P2P network before they
have a justification, as desired. Unfortunately, they never were. This
works around that.
* Add an assert to verify proposed children aren't best
* Consolidate C and I generics into a TendermintClient trait alias
* Expand sanity checks
Substrate doesn't expect nor officially support children with less work
than their parents. It's a trick used here. Accordingly, ensure the
trick's validity.
* When resetting, use the end time of the round which was committed to
The machine reset to the end time of the current round. For a delayed
network connection, a machine may move ahead in rounds and only later
realize a prior round succeeded. Despite acknowledging that round's
success, it would maintain its delay when moving to the next block,
bricking it.
Done by tracking the end time for each round as they occur.
* Move Commit from including the round to including the round's end_time
The round was usable to build the current clock in an accumulated
fashion, relative to the previous round. The end time is the absolute
metric of it, which can be used to calculate the round number (with all
previous end times).
Substrate now builds off the best block, not genesis, using the end time
included in the justification to start its machine in a synchronized
state.
Knowing the end time of a round, or the round in which block was
committed to, is necessary for nodes to sync up with Tendermint.
Encoding it in the commit ensures it's long lasting and makes it readily
available, without the load of an entire transaction.
* Add a TODO on Tendermint
* Misc bug fixes
* More misc bug fixes
* Clean up lock acquisition
* Merge weights and signing scheme into validators, documenting needed changes
* Add pallet sessions to runtime, create pallet-tendermint
* Update node to use pallet sessions
* Update support URL
* Partial work on correcting pallet calls
* Redo Tendermint folder structure
* TendermintApi, compilation fixes
* Fix the stub round robin
At some point, the modulus was removed causing it to exceed the
validators list and stop proposing.
* Use the validators list from the session pallet
* Basic Gossip Validator
* Correct Substrate Tendermint start block
The Tendermint machine uses the passed in number as the block's being
worked on number. Substrate passed in the already finalized block's
number.
Also updates misc comments.
* Clean generics in Tendermint with a monolith with associated types
* Remove the Future triggering the machine for an async fn
Enables passing data in, such as the network.
* Move TendermintMachine from start_num, time to last_num, time
Provides an explicitly clear API clearer to program around.
Also adds additional time code to handle an edge case.
* Connect the Tendermint machine to a GossipEngine
* Connect broadcast
* Remove machine from TendermintImport
It's not used there at all.
* Merge Verifier into block_import.rs
These two files were largely the same, just hooking into sync structs
with almost identical imports. As this project shapes up, removing dead
weight is appreciated.
* Create a dedicated file for being a Tendermint authority
* Deleted comment code related to PoW
* Move serai_runtime specific code from tendermint/client to node
Renames serai-consensus to sc_tendermint
* Consolidate file structure in sc_tendermint
* Replace best_* with finalized_*
We test their equivalency yet still better to use finalized_* in
general.
* Consolidate references to sr25519 in sc_tendermint
* Add documentation to public structs/functions in sc_tendermint
* Add another missing comment
* Make sign asynchronous
Some relation to https://github.com/serai-dex/serai/issues/95.
* Move sc_tendermint to async sign
* Implement proper checking of inherents
* Take in a Keystore and validator ID
* Remove unnecessary PhantomDatas
* Update node to latest sc_tendermint
* Configure node for a multi-node testnet
* Fix handling of the GossipEngine
* Use a rounded genesis to obtain sufficient synchrony within the Docker env
* Correct Serai d-f names in Docker
* Remove an attempt at caching I don't believe would ever hit
* Add an already in chain check to block import
While the inner should do this for us, we call verify_order on our end
*before* inner to ensure sequential import. Accordingly, we need to
provide our own check.
Removes errors of "non-sequential import" when trying to re-import an
existing block.
* Update the consensus documentation
It was incredibly out of date.
* Add a _ to the validator arg in slash
* Make the dev profile a local testnet profile
Restores a dev profile which only has one validator, locally running.
* Reduce Arcs in TendermintMachine, split Signer from SignatureScheme
* Update sc_tendermint per previous commit
* Restore cache
* Remove error case which shouldn't be an error
* Stop returning errors on already existing blocks entirely
* Correct Dave, Eve, and Ferdie to not run as validators
* Rename dev to devnet
--dev still works thanks to the |. Acheieves a personal preference of
mine with some historical meaning.
* Add message expiry to the Tendermint gossip
* Localize the LibP2P protocol to the blockchain
Follows convention by doing so. Theoretically enables running multiple
blockchains over a single LibP2P connection.
* Add a version to sp-runtime in tendermint-machine
* Add missing trait
* Bump Substrate dependency
Fixes #147.
* Implement Schnorr half-aggregation from https://eprint.iacr.org/2021/350.pdf
Relevant to https://github.com/serai-dex/serai/issues/99.
* cargo update (tendermint)
* Move from polling loops to a pure IO model for sc_tendermint's gossip
* Correct protocol name handling
* Use futures mpsc instead of tokio
* Timeout futures
* Move from a yielding loop to select in tendermint-machine
* Update Substrate to the new TendermintHandle
* Use futures pin instead of tokio
* Only recheck blocks with non-fatal inherent transaction errors
* Update to the latest substrate
* Separate the block processing time from the latency
* Add notes to the runtime
* Don't spam slash
Also adds a slash condition of failing to propose.
* Support running TendermintMachine when not a validator
This supports validators who leave the current set, without crashing
their nodes, along with nodes trying to become validators (who will now
seamlessly transition in).
* Properly define and pass around the block size
* Correct the Duration timing
The proposer will build it, send it, then process it (on the first
round). Accordingly, it's / 3, not / 2, as / 2 only accounted for the
latter events.
* Correct time-adjustment code on round skip
* Have the machine respond to advances made by an external sync loop
* Clean up time code in tendermint-machine
* BlockData and RoundData structs
* Rename Round to RoundNumber
* Move BlockData to a new file
* Move Round to an Option due to the pseudo-uninitialized state we create
Before the addition of RoundData, we always created the round, and on
.round(0), simply created it again. With RoundData, and the changes to
the time code, we used round 0, time 0, the latter being incorrect yet
not an issue due to lack of misuse.
Now, if we do misuse it, it'll panic.
* Clear the Queue instead of draining and filtering
There shouldn't ever be a message which passes the filter under the
current design.
* BlockData::new
* Move more code into block.rs
Introduces type-aliases to obtain Data/Message/SignedMessage solely from
a Network object.
Fixes a bug regarding stepping when you're not an active validator.
* Have verify_precommit_signature return if it verified the signature
Also fixes a bug where invalid precommit signatures were left standing
and therefore contributing to commits.
* Remove the precommit signature hash
It cached signatures per-block. Precommit signatures are bound to each
round. This would lead to forming invalid commits when a commit should
be formed. Under debug, the machine would catch that and panic. On
release, it'd have everyone who wasn't a validator fail to continue
syncing.
* Slight doc changes
Also flattens the message handling function by replacing an if
containing all following code in the function with an early return for
the else case.
* Always produce notifications for finalized blocks via origin overrides
* Correct weird formatting
* Update to the latest tendermint-machine
* Manually step the Tendermint machine when we synced a block over the network
* Ignore finality notifications for old blocks
* Remove a TODO resolved in 8c51bc011d03c8d54ded05011e7f4d1a01e9f873
* Add a TODO comment to slash
Enables searching for the case-sensitive phrase and finding it.
* cargo fmt
* Use a tmp DB for Serai in Docker
* Remove panic on slash
As we move towards protonet, this can happen (if a node goes offline),
yet it happening brings down the entire net right now.
* Add log::error on slash
* created shared volume between containers
* Complete the sh scripts
* Pass in the genesis time to Substrate
* Correct block announcements
They were announced, yet not marked best.
* Correct pupulate_end_time
It was used as inclusive yet didn't work inclusively.
* Correct gossip channel jumping when a block is synced via Substrate
* Use a looser check in import_future
This triggered so it needs to be accordingly relaxed.
* Correct race conditions between add_block and step
Also corrects a <= to <.
* Update cargo deny
* rename genesis-service to genesis
* Update Cargo.lock
* Correct runtime Cargo.toml whitespace
* Correct typo
* Document recheck
* Misc lints
* Fix prev commit
* Resolve low-hanging review comments
* Mark genesis/entry-dev.sh as executable
* Prevent a commit from including the same signature multiple times
Yanks tendermint-machine 0.1.0 accordingly.
* Update to latest nightly clippy
* Improve documentation
* Use clearer variable names
* Add log statements
* Pair more log statements
* Clean TendermintAuthority::authority as possible
Merges it into new. It has way too many arguments, yet there's no clear path at
consolidation there, unfortunately.
Additionally provides better scoping within itself.
* Fix #158
Doesn't use lock_import_and_run for reasons commented (lack of async).
* Rename guard to lock
* Have the devnet use the current time as the genesis
Possible since it's only a single node, not requiring synchronization.
* Fix gossiping
I really don't know what side effect this avoids and I can't say I care at this
point.
* Misc lints
Co-authored-by: vrx00 <vrx00@proton.me>
Co-authored-by: TheArchitect108 <TheArchitect108@protonmail.com>
2022-12-03 23:38:02 +00:00
|
|
|
"thiserror",
|
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "termcolor"
|
2024-01-17 00:32:30 +00:00
|
|
|
version = "1.4.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-17 00:32:30 +00:00
|
|
|
checksum = "06794f8f6c5c898b3275aebefa6b8a1cb24cd2c6c79397ab15774837a0bc5755"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"winapi-util",
|
|
|
|
]
|
|
|
|
|
2022-10-20 05:05:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "termtree"
|
2023-03-16 23:37:32 +00:00
|
|
|
version = "0.4.1"
|
2022-10-20 05:05:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-16 23:37:32 +00:00
|
|
|
checksum = "3369f5ac52d5eb6ab48c6b4ffdc8efbcad6b89c765749064ba298f2c68a16a76"
|
2022-10-20 05:05:36 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "thiserror"
|
2024-07-18 19:18:08 +00:00
|
|
|
version = "1.0.63"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-18 19:18:08 +00:00
|
|
|
checksum = "c0342370b38b6a11b6cc11d6a805569958d54cfa061a29969c3b5ce2ea405724"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"thiserror-impl",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "thiserror-impl"
|
2024-07-18 19:18:08 +00:00
|
|
|
version = "1.0.63"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-18 19:18:08 +00:00
|
|
|
checksum = "a4558b58466b9ad7ca0f102865eccc95938dca1a74a856f2b57b6629050da261"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "thread_local"
|
2024-02-25 23:37:15 +00:00
|
|
|
version = "1.1.8"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-25 23:37:15 +00:00
|
|
|
checksum = "8b9ef9bad013ada3808854ceac7b46812a6465ba368859a37e2100283d2d719c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-03-06 12:39:43 +00:00
|
|
|
"cfg-if",
|
2022-07-16 21:49:35 +00:00
|
|
|
"once_cell",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "threadpool"
|
|
|
|
version = "1.8.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d050e60b33d41c19108b32cea32164033a9013fe3b46cbd4457559bfbf77afaa"
|
|
|
|
dependencies = [
|
|
|
|
"num_cpus",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "time"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.3.36"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "5dfd88e563464686c916c7e46e623e520ddc6d79fa6641390f2e3fa86e83e885"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-08-06 06:36:16 +00:00
|
|
|
"deranged",
|
2023-08-25 03:55:47 +00:00
|
|
|
"itoa",
|
2024-05-21 12:07:32 +00:00
|
|
|
"num-conv",
|
2023-10-19 04:02:27 +00:00
|
|
|
"powerfmt",
|
2022-11-04 12:07:37 +00:00
|
|
|
"serde",
|
|
|
|
"time-core",
|
2023-08-25 03:55:47 +00:00
|
|
|
"time-macros",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2022-11-04 12:07:37 +00:00
|
|
|
[[package]]
|
|
|
|
name = "time-core"
|
2023-09-24 12:31:13 +00:00
|
|
|
version = "0.1.2"
|
2022-11-04 12:07:37 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-24 12:31:13 +00:00
|
|
|
checksum = "ef927ca75afb808a4d64dd374f00a2adf8d0fcff8e7b184af886c3c87ec4a3f3"
|
2022-11-04 12:07:37 +00:00
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "time-macros"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.2.18"
|
2023-08-25 03:55:47 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "3f252a68540fde3a3877aeea552b832b40ab9a69e318efd078774a01ddee1ccf"
|
2023-08-25 03:55:47 +00:00
|
|
|
dependencies = [
|
2024-05-21 12:07:32 +00:00
|
|
|
"num-conv",
|
2023-08-25 03:55:47 +00:00
|
|
|
"time-core",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tiny-bip39"
|
2023-01-16 15:42:31 +00:00
|
|
|
version = "1.0.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-01-16 15:42:31 +00:00
|
|
|
checksum = "62cc94d358b5a1e84a5cb9109f559aa3c4d634d2b1b4de3d0fa4adc7c78e2861"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
2023-07-28 03:38:04 +00:00
|
|
|
"hmac",
|
2022-07-16 21:49:35 +00:00
|
|
|
"once_cell",
|
2023-01-16 15:42:31 +00:00
|
|
|
"pbkdf2 0.11.0",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rustc-hash",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"unicode-normalization",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tiny-keccak"
|
|
|
|
version = "2.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "2c9d3793400a45f954c52e73d068316d76b6f4e36977e3fcebb13a2721e80237"
|
|
|
|
dependencies = [
|
|
|
|
"crunchy",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tinyvec"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.8.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "445e881f4f6d382d5f27c034e25eb92edd7c784ceab92a0937db7f2e9471b938"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"tinyvec_macros",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tinyvec_macros"
|
2023-03-06 12:39:43 +00:00
|
|
|
version = "0.1.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-06 12:39:43 +00:00
|
|
|
checksum = "1f3ccbac311fea05f86f61904b462b55fb3df8837a366dfc601a0161d0532f20"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "1.40.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "e2b070231665d27ad9ec9b8df639893f46727666c6767db40317fbe920a5d998"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-06-28 18:57:58 +00:00
|
|
|
"backtrace",
|
2022-07-16 21:49:35 +00:00
|
|
|
"bytes",
|
|
|
|
"libc",
|
|
|
|
"mio",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
"signal-hook-registry",
|
2024-05-21 10:09:04 +00:00
|
|
|
"socket2 0.5.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tokio-macros",
|
2024-08-01 08:06:09 +00:00
|
|
|
"windows-sys 0.52.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio-macros"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "2.4.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "693d596312e88961bc67d7f1f97af8a70227d9f90c31bba5806eec004978d752"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-06-22 10:25:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tokio-rustls"
|
2024-03-27 04:17:04 +00:00
|
|
|
version = "0.26.0"
|
2023-06-22 10:25:30 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-27 04:17:04 +00:00
|
|
|
checksum = "0c7bc40d0e5a97695bb96e27995cd3a08538541b0a846f65bba7a359f36700d4"
|
2023-06-22 10:25:30 +00:00
|
|
|
dependencies = [
|
2024-08-01 08:06:09 +00:00
|
|
|
"rustls 0.23.12",
|
2024-01-17 00:32:30 +00:00
|
|
|
"rustls-pki-types",
|
2023-06-22 10:25:30 +00:00
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tokio-stream"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.16"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "4f4e6ce100d0eb49a2734f8c0812bcd324cf357d21810932c5df6b96ef2b86f1"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures-core",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tokio",
|
2023-01-16 15:42:31 +00:00
|
|
|
"tokio-util",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tokio-util"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.7.12"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "61e7c3654c13bcd040d4a03abee2c75b1d14a37b423cf5a813ceae1cc903ec6a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytes",
|
|
|
|
"futures-core",
|
|
|
|
"futures-io",
|
|
|
|
"futures-sink",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tokio",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "toml"
|
2023-01-28 06:47:13 +00:00
|
|
|
version = "0.5.11"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-01-28 06:47:13 +00:00
|
|
|
checksum = "f4f7f0dd8d50a853a531c426359045b1998f04219d88799810762cd4ad314234"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "toml"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.7.8"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "dd79e69d3b627db300ff956027cc6c3798cef26d22526befdfcd12feeb6d2257"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
"serde_spanned",
|
|
|
|
"toml_datetime",
|
2023-11-25 09:01:11 +00:00
|
|
|
"toml_edit 0.19.15",
|
2023-03-25 04:45:33 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "toml_datetime"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.6.8"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "0dd7358ecb8fc2f8d014bf86f6f638ce72ba252a2c3a2572f2a795f1d23efb41"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "toml_edit"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.19.15"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "1b5bb770da30e5cbfde35a2d7b9b8a2c4b8ef89548a7a6aeab5c9a576e3e7421"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2023-03-25 04:45:33 +00:00
|
|
|
"serde",
|
|
|
|
"serde_spanned",
|
|
|
|
"toml_datetime",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"winnow 0.5.40",
|
2023-03-25 04:45:33 +00:00
|
|
|
]
|
|
|
|
|
2023-11-25 09:01:11 +00:00
|
|
|
[[package]]
|
|
|
|
name = "toml_edit"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.22.20"
|
2023-11-25 09:01:11 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "583c44c02ad26b0c3f3066fe629275e50627026c51ac2e595cca4c230ce1ce1d"
|
2023-11-25 09:01:11 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2023-11-25 09:01:11 +00:00
|
|
|
"toml_datetime",
|
2024-09-05 21:03:23 +00:00
|
|
|
"winnow 0.6.18",
|
2023-11-25 09:01:11 +00:00
|
|
|
]
|
|
|
|
|
2023-01-04 08:17:36 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tower"
|
|
|
|
version = "0.4.13"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "b8fa9be0de6cf49e536ce1851f987bd21a43b771b09473c3549a6c853db37c1c"
|
|
|
|
dependencies = [
|
2024-01-17 00:32:30 +00:00
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
|
|
|
"pin-project",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2024-01-17 00:32:30 +00:00
|
|
|
"tokio",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tower-layer",
|
|
|
|
"tower-service",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tower-http"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.4.4"
|
2023-01-04 08:17:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "61c5bb1d698276a2443e5ecfabc1008bf15a36c12e6a7176e7bf089ea9131140"
|
2023-01-04 08:17:36 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"bitflags 2.6.0",
|
2023-01-04 08:17:36 +00:00
|
|
|
"bytes",
|
|
|
|
"futures-core",
|
|
|
|
"futures-util",
|
2024-03-27 04:17:04 +00:00
|
|
|
"http 0.2.12",
|
2024-01-17 00:32:30 +00:00
|
|
|
"http-body 0.4.6",
|
2023-01-04 08:17:36 +00:00
|
|
|
"http-range-header",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tower-layer",
|
|
|
|
"tower-service",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tower-layer"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.3"
|
2023-01-04 08:17:36 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "121c2a6cda46980bb0fcd1647ffaf6cd3fc79a013de288782836f6df9c48780e"
|
2023-01-04 08:17:36 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tower-service"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.3"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "8df9b6e13f2d32c91b9bd719c00d1958837bc7dec474d94952798cc8e69eeec3"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing"
|
2023-10-19 01:45:49 +00:00
|
|
|
version = "0.1.40"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 01:45:49 +00:00
|
|
|
checksum = "c3523ab5a71916ccf420eebdf5521fcef02141234bbc0b8a49f2fdc4544364ef"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-01-04 08:17:36 +00:00
|
|
|
"log",
|
2024-07-18 19:18:08 +00:00
|
|
|
"pin-project-lite",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tracing-attributes",
|
|
|
|
"tracing-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-attributes"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.1.27"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "34704c8d6ebcbc939824180af020566b01a7c01f80641264eba0999f6c2b6be7"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-core"
|
2023-10-16 03:57:45 +00:00
|
|
|
version = "0.1.32"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-16 03:57:45 +00:00
|
|
|
checksum = "c06d3da6113f116aaee68e4d601191614c9053067f9ab7f6edbcb161237daa54"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"once_cell",
|
|
|
|
"valuable",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-futures"
|
|
|
|
version = "0.2.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "97d095ae15e245a057c8e8451bab9b3ee1e1f68e9ba2b4fbc18d0ac5237835f2"
|
|
|
|
dependencies = [
|
|
|
|
"pin-project",
|
|
|
|
"tracing",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-log"
|
2023-10-24 08:03:51 +00:00
|
|
|
version = "0.1.4"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-24 08:03:51 +00:00
|
|
|
checksum = "f751112709b4e791d8ce53e32c4ed2d353565a795ce84da2285393f41557bdf2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"log",
|
2023-10-24 08:03:51 +00:00
|
|
|
"once_cell",
|
2022-07-16 21:49:35 +00:00
|
|
|
"tracing-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-serde"
|
|
|
|
version = "0.1.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "bc6b213177105856957181934e4920de57730fc69bf42c37ee5bb664d406d9e1"
|
|
|
|
dependencies = [
|
|
|
|
"serde",
|
|
|
|
"tracing-core",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tracing-subscriber"
|
|
|
|
version = "0.2.25"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "0e0d2eaa99c3c2e41547cfa109e910a68ea03823cccad4a0525dcbc9b01e8c71"
|
|
|
|
dependencies = [
|
|
|
|
"ansi_term",
|
|
|
|
"chrono",
|
|
|
|
"lazy_static",
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
"matchers 0.0.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"parking_lot 0.11.2",
|
|
|
|
"regex",
|
|
|
|
"serde",
|
|
|
|
"serde_json",
|
|
|
|
"sharded-slab",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thread_local",
|
|
|
|
"tracing",
|
|
|
|
"tracing-core",
|
|
|
|
"tracing-log",
|
|
|
|
"tracing-serde",
|
|
|
|
]
|
|
|
|
|
Add support for multiple multisigs to the processor (#377)
* Design and document a multisig rotation flow
* Make Scanner::eventualities a HashMap so it's per-key
* Don't drop eventualities, always follow through on them
Technical improvements made along the way.
* Start creating an isolate object to manage multisigs, which doesn't require being a signer
Removes key from SubstrateBlock.
* Move Scanner/Scheduler under multisigs
* Move Batch construction into MultisigManager
* Clarify "should" in Multisig Rotation docs
* Add block_number to MultisigManager, as it controls the scanner
* Move sign_plans into MultisigManager
Removes ThresholdKeys from prepare_send.
* Make SubstrateMutable an alias for MultisigManager
* Rewrite Multisig Rotation
The prior scheme had an exploit possible where funds were sent to the old
multisig, then burnt on Serai to send from the new multisig, locking liquidity
for 6 hours. While a fee could be applied to stragglers, to make this attack
unprofitable, the newly described scheme avoids all this.
* Add mini
mini is a miniature version of Serai, emphasizing Serai's nature as a
collection of independent clocks. The intended use is to identify race
conditions and prove protocols are comprehensive regarding when certain clocks
tick.
This uses loom, a prior candidate for evaluating the processor/coordinator as
free of race conditions (#361).
* Use mini to prove a race condition in the current multisig rotation docs, and prove safety of alternatives
Technically, the prior commit had mini prove the race condition.
The docs currently say the activation block of the new multisig is the block
after the next Batch's. If the two next Batches had already entered the
mempool, prior to set_keys being called, the second next Batch would be
expected to contain the new key's data yet fail to as the key wasn't public
when the Batch was actually created.
The naive solution is to create a Batch, publish it, wait until it's included,
and only then scan the next block. This sets a bound of
`Batch publication time < block time`. Optimistically, we can publish a Batch
in 24s while our shortest block time is 2m. Accordingly, we should be fine with
the naive solution which doesn't take advantage of throughput. #333 may
significantly change latency however and require an algorithm whose throughput
exceeds the rate of blocks created.
In order to re-introduce parallelization, enabling throughput, we need to
define a safe range of blocks to scan without Serai ordering the first one.
mini demonstrates safety of scanning n blocks Serai hasn't acknowledged, so
long as the first is scanned before block n+1 is (shifting the n-block window).
The docs will be updated next, to reflect this.
* Fix Multisig Rotation
I believe this is finally good enough to be final.
1) Fixes the race condition present in the prior document, as demonstrated by
mini.
`Batch`s for block `n` and `n+1`, may have been in the mempool when a
multisig's activation block was set to `n`. This would cause a potentially
distinct `Batch` for `n+1`, despite `n+1` already having a signed `Batch`.
2) Tightens when UIs should use the new multisig to prevent eclipse attacks,
and protection against `Batch` publication delays.
3) Removes liquidity fragmentation by tightening flow/handling of latency.
4) Several clarifications and documentation of reasoning.
5) Correction of "prior multisig" to "all prior multisigs" regarding historical
verification, with explanation why.
* Clarify terminology in mini
Synchronizes it from my original thoughts on potential schema to the design
actually created.
* Remove most of processor's README for a reference to docs/processor
This does drop some misc commentary, though none too beneficial. The section on
scanning, deemed sufficiently beneficial, has been moved to a document and
expanded on.
* Update scanner TODOs in line with new docs
* Correct documentation on Bitcoin::Block::time, and Block::time
* Make the scanner in MultisigManager no longer public
* Always send ConfirmKeyPair, regardless of if in-set
* Cargo.lock changes from a prior commit
* Add a policy document on defining a Canonical Chain
I accidentally committed a version of this with a few headers earlier, and this
is a proper version.
* Competent MultisigManager::new
* Update processor's comments
* Add mini to copied files
* Re-organize Scanner per multisig rotation document
* Add RUST_LOG trace targets to e2e tests
* Have the scanner wait once it gets too far ahead
Also bug fixes.
* Add activation blocks to the scanner
* Split received outputs into existing/new in MultisigManager
* Select the proper scheduler
* Schedule multisig activation as detailed in documentation
* Have the Coordinator assert if multiple `Batch`s occur within a block
While the processor used to have ack_up_to_block, enabling skips in the block
acked, support for this was removed while reworking it for multiple multisigs.
It should happen extremely infrequently.
While it would still be beneficial to have, if multiple `Batch`s could occur
within a block (with the complexity here not being worth adding that ban as a
policy), multiple `Batch`s were blocked for DoS reasons.
* Schedule payments to the proper multisig
* Correct >= to <
* Use the new multisig's key for change on schedule
* Don't report External TXs to prior multisig once deprecated
* Forward from the old multisig to the new one at all opportunities
* Move unfulfilled payments in queue from prior to new multisig
* Create MultisigsDb, splitting it out of MainDb
Drops the call to finish_signing from the Signer. While this will cause endless
re-attempts, the Signer will still consider them completed and drop them,
making this an O(n) cost at boot even if we did nothing from here.
The MultisigManager should call finish_signing once the Scanner completes the
Eventuality.
* Don't check Scanner-emitted completions, trust they are completions
Prevents needing to use async code to mark the completion and creates a
fault-free model. The current model, on fault, would cause a lack of marked
completion in the signer.
* Fix a possible panic in the processor
A shorter-chain reorg could cause this assert to trip. It's fixed by
de-duplicating the data, as the assertion checked consistency. Without the
potential for inconsistency, it's unnecessary.
* Document why an existing TODO isn't valid
* Change when we drop payments for being to the change address
The earlier timing prevents creating Plans solely to the branch address,
causing the payments to be dropped, and the TX to become an effective
aggregation TX.
* Extensively document solutions to Eventualities being potentially created after having already scanned their resolutions
* When closing, drop External/Branch outputs which don't cause progress
* Properly decide if Change outputs should be forward or not when closing
This completes all code needed to make the old multisig have a finite lifetime.
* Commentary on forwarding schemes
* Provide a 1 block window, with liquidity fragmentation risks, due to latency
On Bitcoin, this will be 10 minutes for the relevant Batch to be confirmed. On
Monero, 2 minutes. On Ethereum, ~6 minutes.
Also updates the Multisig Rotation document with the new forwarding plan.
* Implement transaction forwarding from old multisig to new multisig
Identifies a fault where Branch outputs which shouldn't be dropped may be, if
another output fulfills their next step. Locking Branch fulfillment down to
only Branch outputs is not done in this commit, but will be in the next.
* Only let Branch outputs fulfill branches
* Update TODOs
* Move the location of handling signer events to avoid a race condition
* Avoid a deadlock by using a RwLock on a single txn instead of two txns
* Move Batch ID out of the Scanner
* Increase from one block of latency on new keys activation to two
For Monero, this offered just two minutes when our latency to publish a Batch
is around a minute already. This does increase the time our liquidity can be
fragmented by up to 20 minutes (Bitcoin), yet it's a stupid attack only
possible once a week (when we rotate). Prioritizing normal users' transactions
not being subject to forwarding is more important here.
Ideally, we'd not do +2 blocks yet plus `time`, such as +10 minutes, making
this agnostic of the underlying network's block scheduling. This is a
complexity not worth it.
* Split MultisigManager::substrate_block into multiple functions
* Further tweaks to substrate_block
* Acquire a lock on all Scanner operations after calling ack_block
Gives time to call register_eventuality and initiate signing.
* Merge sign_plans into substrate_block
Also ensure the Scanner's lock isn't prematurely released.
* Use a HashMap to pass to-be-forwarded instructions, not the DB
* Successfully determine in ClosingExisting
* Move from 2 blocks of latency when rotating to 10 minutes
Superior as noted in 6d07af92ce10cfd74c17eb3400368b0150eb36d7, now trivial to
implement thanks to prior commit.
* Add note justifying measuring time in blocks when rotating
* Implement delaying of outputs received early to the new multisig per specification
* Documentation on why Branch outputs don't have the race condition concerns Change do
Also ensures 6 hours is at least N::CONFIRMATIONS, for sanity purposes.
* Remove TODO re: sanity checking Eventualities
We sanity check the Plan the Eventuality is derived from, and the Eventuality
is handled moments later (in the same file, with a clear call path). There's no
reason to add such APIs to Eventualities for a sanity check given that.
* Add TODO(now) for TODOs which must be done in this branch
Also deprecates a pair of TODOs to TODO2, and accepts the flow of the Signer
having the Eventuality.
* Correct errors in potential/future flow descriptions
* Accept having a single Plan Vec
Per the following code consuming it, there's no benefit to bifurcating it by
key.
* Only issue sign_transaction on boot for the proper signer
* Only set keys when participating in their construction
* Misc progress
Only send SubstrateBlockAck when we have a signer, as it's only used to tell
the Tributary of what Plans are being signed in response to this block.
Only immediately sets substrate_signer if session is 0.
On boot, doesn't panic if we don't have an active key (as we wouldn't if only
joining the next multisig). Continues.
* Correctly detect and set retirement block
Modifies the retirement block from first block meeting requirements to block
CONFIRMATIONS after.
Adds an ack flow to the Scanner's Confirmed event and Block event to accomplish
this, which may deadlock at this time (will be fixed shortly).
Removes an invalid await (after a point declared unsafe to use await) from
MultisigsManager::next_event.
* Remove deadlock in multisig_completed and document alternative
The alternative is simpler, albeit less efficient. There's no reason to adopt
it now, yet perhaps if it benefits modeling?
* Handle the final step of retirement, dropping the old key and setting new to existing
* Remove TODO about emitting a Block on every step
If we emit on NewAsChange, we lose the purpose of the NewAsChange period.
The only concern is if we reach ClosingExisting, and nothing has happened, then
all coins will still be in the old multisig until something finally does. This
isn't a problem worth solving, as it's latency under exceptional dead time.
* Add TODO about potentially not emitting a Block event for the reitrement block
* Restore accidentally deleted CI file
* Pair of slight tweaks
* Add missing if statement
* Disable an assertion when testing
One of the test flows currently abuses the Scanner in a way triggering it.
2023-09-25 13:48:15 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tracing-subscriber"
|
|
|
|
version = "0.3.17"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "30a651bc37f915e81f087d86e62a18eec5f79550c7faff886f7090b4ea757c77"
|
|
|
|
dependencies = [
|
|
|
|
"matchers 0.1.0",
|
|
|
|
"nu-ansi-term",
|
|
|
|
"once_cell",
|
|
|
|
"regex",
|
|
|
|
"sharded-slab",
|
|
|
|
"smallvec",
|
|
|
|
"thread_local",
|
|
|
|
"tracing",
|
|
|
|
"tracing-core",
|
|
|
|
"tracing-log",
|
|
|
|
]
|
|
|
|
|
2023-04-11 14:18:31 +00:00
|
|
|
[[package]]
|
|
|
|
name = "tributary-chain"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2023-04-14 01:05:18 +00:00
|
|
|
"async-trait",
|
2023-04-11 23:04:53 +00:00
|
|
|
"blake2",
|
|
|
|
"ciphersuite",
|
2023-04-14 01:05:18 +00:00
|
|
|
"flexible-transcript",
|
2023-12-11 00:32:43 +00:00
|
|
|
"futures-channel",
|
|
|
|
"futures-util",
|
2023-04-14 01:05:18 +00:00
|
|
|
"hex",
|
|
|
|
"log",
|
|
|
|
"parity-scale-codec",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
|
|
|
"rand_chacha",
|
2023-04-11 23:04:53 +00:00
|
|
|
"schnorr-signatures",
|
2023-04-14 18:11:19 +00:00
|
|
|
"serai-db",
|
2023-04-14 01:05:18 +00:00
|
|
|
"subtle",
|
2023-04-11 14:18:31 +00:00
|
|
|
"tendermint-machine",
|
2023-04-11 23:04:53 +00:00
|
|
|
"thiserror",
|
2023-04-14 01:05:18 +00:00
|
|
|
"tokio",
|
2023-04-12 12:51:40 +00:00
|
|
|
"zeroize",
|
2023-04-11 14:18:31 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "trie-db"
|
2023-03-26 12:43:01 +00:00
|
|
|
version = "0.27.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-26 12:43:01 +00:00
|
|
|
checksum = "767abe6ffed88a1889671a102c2861ae742726f52e0a5a425b92c9fbfa7e9c85"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"hash-db",
|
2023-03-06 12:39:43 +00:00
|
|
|
"hashbrown 0.13.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
|
|
|
"rustc-hex",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "trie-root"
|
2023-03-26 12:43:01 +00:00
|
|
|
version = "0.18.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-26 12:43:01 +00:00
|
|
|
checksum = "d4ed310ef5ab98f5fa467900ed906cb9232dd5376597e00fd4cba2a449d06c0b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"hash-db",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "trust-dns-proto"
|
2022-10-20 05:05:36 +00:00
|
|
|
version = "0.22.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-10-20 05:05:36 +00:00
|
|
|
checksum = "4f7f83d1e4a0e4358ac54c5c3681e5d7da5efc5a7a632c90bb6d6669ddd9bc26"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"cfg-if",
|
|
|
|
"data-encoding",
|
2023-10-19 04:27:21 +00:00
|
|
|
"enum-as-inner 0.5.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"futures-channel",
|
|
|
|
"futures-io",
|
|
|
|
"futures-util",
|
2022-09-18 19:30:38 +00:00
|
|
|
"idna 0.2.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"ipnet",
|
|
|
|
"lazy_static",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2023-10-23 04:33:38 +00:00
|
|
|
"socket2 0.4.10",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
|
|
|
"tinyvec",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tokio",
|
2022-10-20 05:05:36 +00:00
|
|
|
"tracing",
|
2022-07-16 21:49:35 +00:00
|
|
|
"url",
|
|
|
|
]
|
|
|
|
|
2023-10-19 04:27:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "trust-dns-proto"
|
2023-10-24 08:03:51 +00:00
|
|
|
version = "0.23.2"
|
2023-10-19 04:27:21 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-24 08:03:51 +00:00
|
|
|
checksum = "3119112651c157f4488931a01e586aa459736e9d6046d3bd9105ffb69352d374"
|
2023-10-19 04:27:21 +00:00
|
|
|
dependencies = [
|
|
|
|
"async-trait",
|
|
|
|
"cfg-if",
|
|
|
|
"data-encoding",
|
|
|
|
"enum-as-inner 0.6.0",
|
|
|
|
"futures-channel",
|
|
|
|
"futures-io",
|
|
|
|
"futures-util",
|
|
|
|
"idna 0.4.0",
|
|
|
|
"ipnet",
|
|
|
|
"once_cell",
|
|
|
|
"rand",
|
|
|
|
"smallvec",
|
|
|
|
"thiserror",
|
|
|
|
"tinyvec",
|
|
|
|
"tokio",
|
|
|
|
"tracing",
|
|
|
|
"url",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "trust-dns-resolver"
|
2023-10-24 08:03:51 +00:00
|
|
|
version = "0.23.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-24 08:03:51 +00:00
|
|
|
checksum = "10a3e6c3aff1718b3c73e395d1f35202ba2ffa847c6a62eea0db8fb4cfe30be6"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"futures-util",
|
|
|
|
"ipconfig",
|
|
|
|
"lru-cache",
|
2023-10-19 04:27:21 +00:00
|
|
|
"once_cell",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-10-19 04:27:21 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"resolv-conf",
|
2023-09-20 08:30:46 +00:00
|
|
|
"smallvec",
|
2022-07-16 21:49:35 +00:00
|
|
|
"thiserror",
|
2023-01-04 08:17:36 +00:00
|
|
|
"tokio",
|
2022-10-20 05:05:36 +00:00
|
|
|
"tracing",
|
2023-10-24 08:03:51 +00:00
|
|
|
"trust-dns-proto 0.23.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "try-lock"
|
2023-12-15 05:54:39 +00:00
|
|
|
version = "0.2.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-15 05:54:39 +00:00
|
|
|
checksum = "e421abadd41a4225275504ea4d6566923418b7f05506fbc9c0fe86ba7396114b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "tt-call"
|
2022-12-21 04:12:26 +00:00
|
|
|
version = "1.0.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-12-21 04:12:26 +00:00
|
|
|
checksum = "f4f195fd851901624eee5a58c4bb2b4f06399148fcd0ed336e6f1cb60a9881df"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "twox-hash"
|
|
|
|
version = "1.6.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "97fee6b57c6a41524a810daee9286c02d7752c4253064d0b05472833a438f675"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-06-22 10:25:30 +00:00
|
|
|
"digest 0.10.7",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"static_assertions",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "typenum"
|
2023-09-20 08:30:46 +00:00
|
|
|
version = "1.17.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-20 08:30:46 +00:00
|
|
|
checksum = "42ff0bf0c66b8238c6f3b578df37d0b7848e55df8577b3f74f92a69acceeb825"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "ucd-trie"
|
|
|
|
version = "0.1.6"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ed646292ffc8188ef8ea4d1e0e0150fb15a5c2e12ad9b8fc191ae7a8a7f3c4b9"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "uint"
|
2022-12-07 22:56:53 +00:00
|
|
|
version = "0.9.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-12-07 22:56:53 +00:00
|
|
|
checksum = "76f64bba2c53b04fcab63c01a7d7427eadc821e3bc48c34dc9ba29c501164b52"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"byteorder",
|
|
|
|
"crunchy",
|
|
|
|
"hex",
|
|
|
|
"static_assertions",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "unarray"
|
|
|
|
version = "0.1.4"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "eaea85b334db583fe3274d12b4cd1880032beab409c0d774be044d4480ab9a94"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "unicode-bidi"
|
2024-01-19 16:44:49 +00:00
|
|
|
version = "0.3.15"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-01-19 16:44:49 +00:00
|
|
|
checksum = "08f95100a766bf4f8f28f90d77e0a5461bbdb219042e7679bebe79004fed8d75"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicode-ident"
|
2023-09-20 08:30:46 +00:00
|
|
|
version = "1.0.12"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-20 08:30:46 +00:00
|
|
|
checksum = "3354b9ac3fae1ff6755cb6db53683adb661634f67557942dea4facebec0fee4b"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicode-normalization"
|
2024-02-25 23:37:15 +00:00
|
|
|
version = "0.1.23"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-25 23:37:15 +00:00
|
|
|
checksum = "a56d1686db2308d901306f92a263857ef59ea39678a5458e7cb17f01415101f5"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"tinyvec",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicode-width"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "0.1.13"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "0336d538f7abc86d282a4189614dfaa90810dfc2c6f6427eaf88e16311dd225d"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unicode-xid"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "229730647fbc343e3a80e463c1db7f78f3855d3f3739bee0dda773c9a037c90a"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "universal-hash"
|
2023-11-12 05:40:32 +00:00
|
|
|
version = "0.5.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-11-12 05:40:32 +00:00
|
|
|
checksum = "fc1de2c688dc15305988b563c3854064043356019f97a4b46276fe734c4f07ea"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-11-12 05:40:32 +00:00
|
|
|
"crypto-common",
|
2022-07-16 21:49:35 +00:00
|
|
|
"subtle",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "unsigned-varint"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "0.7.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "6889a77d49f1f013504cec6bf97a2c730394adedaeb1deb5ea08949a50541105"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"asynchronous-codec",
|
|
|
|
"bytes",
|
|
|
|
"futures-io",
|
|
|
|
"futures-util",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "untrusted"
|
|
|
|
version = "0.7.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "a156c684c91ea7d62626509bce3cb4e1d9ed5c4d978f7b4352658f96a4c26b4a"
|
|
|
|
|
2023-11-06 12:19:55 +00:00
|
|
|
[[package]]
|
|
|
|
name = "untrusted"
|
|
|
|
version = "0.9.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "8ecb6da28b8a351d773b68d5825ac39017e680750f980f3a1a85cd8dd28a47c1"
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "url"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "2.5.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "22784dbdf76fdde8af1aeda5622b546b422b6fc585325248a2bf9f5e41e94d6c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"form_urlencoded",
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
"idna 0.5.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"percent-encoding",
|
|
|
|
]
|
|
|
|
|
2023-03-31 06:34:52 +00:00
|
|
|
[[package]]
|
|
|
|
name = "utf8parse"
|
2024-06-19 16:39:47 +00:00
|
|
|
version = "0.2.2"
|
2023-03-31 06:34:52 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-19 16:39:47 +00:00
|
|
|
checksum = "06abde3611657adf66d383f00b093d7faecc7fa57071cce2578660c9f1010821"
|
2023-03-31 06:34:52 +00:00
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "uuid"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "1.10.0"
|
2023-08-23 02:06:06 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "81dfa00651efa65069b0b6b651f4aaa31ba9e3c3ce0137aaad053604ee7e0314"
|
2023-08-23 02:06:06 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "valuable"
|
|
|
|
version = "0.1.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "830b7e5d4d90034032940e4ace0d9a9a057e7a45cd94e6c007832e39edb82f6d"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "vcpkg"
|
|
|
|
version = "0.2.15"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "accd4ea62f7bb7a82fe23066fb0957d48ef677f6eeb8215f372f52e48bb32426"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "version_check"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.9.5"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "0b928f33d975fc6ad9f86c8f283853ad26bdd5b10b7f1542aa2fa15e2289105a"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "void"
|
|
|
|
version = "1.0.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "6a02e4885ed3bc0f2de90ea6dd45ebcbb66dacffe03547fadbb0eeae2770887d"
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "wait-timeout"
|
|
|
|
version = "0.2.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9f200f5b12eb75f8c1ed65abd4b2db8a6e1b138a20de009dacee265a2498f3f6"
|
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "walkdir"
|
2024-03-08 04:21:15 +00:00
|
|
|
version = "2.5.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-03-08 04:21:15 +00:00
|
|
|
checksum = "29790946404f91d9c5d06f9874efddea1dc06c5efe94541a7d6863108e3a5e4b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"same-file",
|
|
|
|
"winapi-util",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "want"
|
2023-06-22 10:25:30 +00:00
|
|
|
version = "0.3.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-06-22 10:25:30 +00:00
|
|
|
checksum = "bfa7760aed19e106de2c7c0b581b509f2f25d3dacaf737cb82ac61bc6d760b0e"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"try-lock",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasi"
|
|
|
|
version = "0.11.0+wasi-snapshot-preview1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "9c8d87e72b64a3b4db28d11ce29237c246188f4f51057d65a7eab63b7987e423"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.93"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "a82edfc16a6c469f5f44dc7b571814045d60404b55a0ee849f9bcfa2e63dd9b5"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2024-09-05 21:03:23 +00:00
|
|
|
"once_cell",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasm-bindgen-macro",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-backend"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.93"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "9de396da306523044d3302746f1208fa71d7532227f15e347e2d93e4145dd77b"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"bumpalo",
|
|
|
|
"log",
|
2022-08-16 07:44:32 +00:00
|
|
|
"once_cell",
|
2022-07-16 21:49:35 +00:00
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasm-bindgen-shared",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-futures"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.4.43"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "61e9300f63a621e96ed275155c108eb6f843b6a26d053f122ab69724559dc8ed"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-macro"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.93"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "585c4c91a46b072c92e908d99cb1dcdf95c5218eeb6f3bf1efa991ee7a68cccf"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"quote",
|
|
|
|
"wasm-bindgen-macro-support",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-macro-support"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.93"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "afc340c74d9005395cf9dd098506f7f44e38f2b4a21c6aaacf9a105ea5e1e836"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasm-bindgen-backend",
|
|
|
|
"wasm-bindgen-shared",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-bindgen-shared"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.2.93"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "c62a0a307cb4a311d3a07867860911ca130c3494e8c2719593806c08bc5d0484"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "wasm-encoder"
|
|
|
|
version = "0.31.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "41763f20eafed1399fff1afb466496d3a959f58241436cfdc17e3f5ca954de16"
|
|
|
|
dependencies = [
|
|
|
|
"leb128",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
2022-11-11 04:59:20 +00:00
|
|
|
name = "wasm-instrument"
|
2023-04-09 06:31:10 +00:00
|
|
|
version = "0.4.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-04-09 06:31:10 +00:00
|
|
|
checksum = "2a47ecb37b9734d1085eaa5ae1a81e60801fd8c28d4cabdd8aedb982021918bc"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-11-11 04:59:20 +00:00
|
|
|
"parity-wasm",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
2022-11-11 04:59:20 +00:00
|
|
|
name = "wasm-opt"
|
2023-10-19 01:45:49 +00:00
|
|
|
version = "0.114.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 01:45:49 +00:00
|
|
|
checksum = "effbef3bd1dde18acb401f73e740a6f3d4a1bc651e9773bddc512fe4d8d68f67"
|
2022-11-11 04:59:20 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"libc",
|
2023-07-19 02:30:55 +00:00
|
|
|
"strum 0.24.1",
|
|
|
|
"strum_macros 0.24.3",
|
2022-11-11 04:59:20 +00:00
|
|
|
"tempfile",
|
|
|
|
"thiserror",
|
|
|
|
"wasm-opt-cxx-sys",
|
|
|
|
"wasm-opt-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-opt-cxx-sys"
|
2023-10-19 01:45:49 +00:00
|
|
|
version = "0.114.2"
|
2022-11-11 04:59:20 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 01:45:49 +00:00
|
|
|
checksum = "c09e24eb283919ace2ed5733bda4842a59ce4c8de110ef5c6d98859513d17047"
|
2022-11-11 04:59:20 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"cxx",
|
|
|
|
"cxx-build",
|
|
|
|
"wasm-opt-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-opt-sys"
|
2023-10-19 01:45:49 +00:00
|
|
|
version = "0.114.2"
|
2022-11-11 04:59:20 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-10-19 01:45:49 +00:00
|
|
|
checksum = "36f2f817bed2e8d65eb779fa37317e74de15585751f903c9118342d1970703a4"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2022-11-11 04:59:20 +00:00
|
|
|
"anyhow",
|
|
|
|
"cc",
|
|
|
|
"cxx",
|
|
|
|
"cxx-build",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasm-timer"
|
|
|
|
version = "0.2.5"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "be0ecb0db480561e9a7642b5d3e4187c128914e58aa84330b9493e3eb68c5e7f"
|
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"js-sys",
|
|
|
|
"parking_lot 0.11.2",
|
|
|
|
"pin-utils",
|
|
|
|
"wasm-bindgen",
|
|
|
|
"wasm-bindgen-futures",
|
|
|
|
"web-sys",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmparser"
|
2023-08-23 02:06:06 +00:00
|
|
|
version = "0.110.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-08-23 02:06:06 +00:00
|
|
|
checksum = "1dfcdb72d96f01e6c85b6bf20102e7423bdbaad5c337301bab2bbf253d26413c"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2024-05-21 10:09:04 +00:00
|
|
|
"semver 1.0.23",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "c4e87029cc5760db9a3774aff4708596fe90c20ed2baeef97212e98b812fd0fc"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"bincode",
|
2023-08-23 02:06:06 +00:00
|
|
|
"bumpalo",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cfg-if",
|
2023-08-23 02:06:06 +00:00
|
|
|
"fxprof-processed-profile",
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libc",
|
|
|
|
"log",
|
2023-08-23 02:06:06 +00:00
|
|
|
"object 0.31.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"once_cell",
|
|
|
|
"paste",
|
|
|
|
"psm",
|
|
|
|
"rayon",
|
|
|
|
"serde",
|
2023-08-23 02:06:06 +00:00
|
|
|
"serde_json",
|
2022-07-16 21:49:35 +00:00
|
|
|
"target-lexicon",
|
2023-08-23 02:06:06 +00:00
|
|
|
"wasm-encoder",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasmparser",
|
|
|
|
"wasmtime-cache",
|
|
|
|
"wasmtime-cranelift",
|
|
|
|
"wasmtime-environ",
|
|
|
|
"wasmtime-jit",
|
|
|
|
"wasmtime-runtime",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-09-29 18:33:09 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-asm-macros"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-09-29 18:33:09 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "96d84f68d831200016e120f2ee79d81b50cf4c4123112914aefb168d036d445d"
|
2022-09-29 18:33:09 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-cache"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "31561fbbaa86d3c042696940bc9601146bf4aaec39ae725c86b5f1358d8d7023"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
2024-01-17 00:32:30 +00:00
|
|
|
"base64 0.21.7",
|
2022-07-16 21:49:35 +00:00
|
|
|
"bincode",
|
|
|
|
"directories-next",
|
|
|
|
"file-per-thread-logger",
|
|
|
|
"log",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
2023-08-23 17:24:21 +00:00
|
|
|
"sha2",
|
2023-03-25 04:45:33 +00:00
|
|
|
"toml 0.5.11",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2023-04-09 06:31:10 +00:00
|
|
|
"zstd 0.11.2+zstd.1.5.2",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-cranelift"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "8ae8ed7a4845f22be6b1ad80f33f43fa03445b03a02f2d40dca695129769cd1a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"cranelift-codegen",
|
2023-08-23 02:06:06 +00:00
|
|
|
"cranelift-control",
|
2022-07-16 21:49:35 +00:00
|
|
|
"cranelift-entity",
|
|
|
|
"cranelift-frontend",
|
|
|
|
"cranelift-native",
|
|
|
|
"cranelift-wasm",
|
2023-08-23 02:06:06 +00:00
|
|
|
"gimli 0.27.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-08-23 02:06:06 +00:00
|
|
|
"object 0.31.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"target-lexicon",
|
|
|
|
"thiserror",
|
|
|
|
"wasmparser",
|
2023-06-28 18:57:58 +00:00
|
|
|
"wasmtime-cranelift-shared",
|
|
|
|
"wasmtime-environ",
|
2023-08-23 02:06:06 +00:00
|
|
|
"wasmtime-versioned-export-macros",
|
2023-06-28 18:57:58 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-cranelift-shared"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2023-06-28 18:57:58 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "86b17099f9320a1c481634d88101258917d5065717cf22b04ed75b1a8ea062b4"
|
2023-06-28 18:57:58 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"cranelift-codegen",
|
2023-08-23 02:06:06 +00:00
|
|
|
"cranelift-control",
|
2023-06-28 18:57:58 +00:00
|
|
|
"cranelift-native",
|
2023-08-23 02:06:06 +00:00
|
|
|
"gimli 0.27.3",
|
|
|
|
"object 0.31.1",
|
2023-06-28 18:57:58 +00:00
|
|
|
"target-lexicon",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasmtime-environ",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-environ"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "e8b9227b1001229ff125e0f76bf1d5b9dc4895e6bcfd5cc35a56f84685964ec7"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"cranelift-entity",
|
2023-08-23 02:06:06 +00:00
|
|
|
"gimli 0.27.3",
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-08-23 02:06:06 +00:00
|
|
|
"object 0.31.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
|
|
|
"target-lexicon",
|
|
|
|
"thiserror",
|
|
|
|
"wasmparser",
|
|
|
|
"wasmtime-types",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-jit"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "cce606b392c321d7272928003543447119ef937a9c3ebfce5c4bb0bf6b0f5bac"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-08-23 02:06:06 +00:00
|
|
|
"addr2line 0.20.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"anyhow",
|
|
|
|
"bincode",
|
|
|
|
"cfg-if",
|
|
|
|
"cpp_demangle",
|
2023-08-23 02:06:06 +00:00
|
|
|
"gimli 0.27.3",
|
2022-07-16 21:49:35 +00:00
|
|
|
"log",
|
2023-08-23 02:06:06 +00:00
|
|
|
"object 0.31.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
"rustc-demangle",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2022-07-16 21:49:35 +00:00
|
|
|
"serde",
|
|
|
|
"target-lexicon",
|
|
|
|
"wasmtime-environ",
|
|
|
|
"wasmtime-jit-debug",
|
2023-03-06 12:39:43 +00:00
|
|
|
"wasmtime-jit-icache-coherence",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasmtime-runtime",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-jit-debug"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "aef27ea6c34ef888030d15560037fe7ef27a5609fbbba8e1e3e41dc4245f5bb2"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-08-23 02:06:06 +00:00
|
|
|
"object 0.31.1",
|
2022-09-29 18:33:09 +00:00
|
|
|
"once_cell",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2023-08-23 02:06:06 +00:00
|
|
|
"wasmtime-versioned-export-macros",
|
2023-03-06 12:39:43 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-jit-icache-coherence"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "b59f94b0409221873565419168e20b5aedf18c4bd64de5c38acf8f0634efeee3"
|
2023-03-06 12:39:43 +00:00
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
|
|
|
"libc",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-runtime"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "ceb587a88ae5bb6ca248455a391aff29ac63329a404b2cdea36d91267c797db4"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"anyhow",
|
|
|
|
"cc",
|
|
|
|
"cfg-if",
|
2024-09-05 21:03:23 +00:00
|
|
|
"indexmap 2.5.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
"libc",
|
|
|
|
"log",
|
|
|
|
"mach",
|
|
|
|
"memfd",
|
2023-08-23 02:06:06 +00:00
|
|
|
"memoffset",
|
2022-09-29 18:33:09 +00:00
|
|
|
"paste",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2023-08-23 02:06:06 +00:00
|
|
|
"sptr",
|
|
|
|
"wasm-encoder",
|
2022-09-29 18:33:09 +00:00
|
|
|
"wasmtime-asm-macros",
|
2022-07-16 21:49:35 +00:00
|
|
|
"wasmtime-environ",
|
|
|
|
"wasmtime-jit-debug",
|
2023-08-23 02:06:06 +00:00
|
|
|
"wasmtime-versioned-export-macros",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-types"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "77943729d4b46141538e8d0b6168915dc5f88575ecdfea26753fd3ba8bab244a"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cranelift-entity",
|
|
|
|
"serde",
|
|
|
|
"thiserror",
|
|
|
|
"wasmparser",
|
|
|
|
]
|
|
|
|
|
2023-08-23 02:06:06 +00:00
|
|
|
[[package]]
|
|
|
|
name = "wasmtime-versioned-export-macros"
|
2023-09-15 18:06:39 +00:00
|
|
|
version = "12.0.2"
|
2023-08-23 02:06:06 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-15 18:06:39 +00:00
|
|
|
checksum = "ca7af9bb3ee875c4907835e607a275d10b04d15623d3aebe01afe8fbd3f85050"
|
2023-08-23 02:06:06 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-08-23 02:06:06 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "web-sys"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.3.70"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "26fdeaafd9bd129f65e7c031593c24d62186301e0c72c8978fa1678be7d532c0"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"js-sys",
|
|
|
|
"wasm-bindgen",
|
|
|
|
]
|
|
|
|
|
2023-08-22 02:58:45 +00:00
|
|
|
[[package]]
|
|
|
|
name = "webpki-roots"
|
2024-02-04 06:13:48 +00:00
|
|
|
version = "0.25.4"
|
2023-08-22 02:58:45 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-04 06:13:48 +00:00
|
|
|
checksum = "5f20c57d8d7db6d3b86154206ae5d8fba62dd39573114de97c2cb0578251f8e1"
|
2023-08-22 02:58:45 +00:00
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "which"
|
2023-09-12 11:47:03 +00:00
|
|
|
version = "4.4.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-09-12 11:47:03 +00:00
|
|
|
checksum = "87ba24419a2078cd2b0f2ede2691b6c66d8e47836da3b6db8265ebad47afbfc7"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"either",
|
2023-09-12 11:47:03 +00:00
|
|
|
"home",
|
2022-09-18 19:30:38 +00:00
|
|
|
"once_cell",
|
2023-11-22 06:24:17 +00:00
|
|
|
"rustix",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-03-06 12:39:43 +00:00
|
|
|
[[package]]
|
|
|
|
name = "wide"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.7.28"
|
2023-03-06 12:39:43 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "b828f995bf1e9622031f8009f8481a85406ce1f4d4588ff746d872043e855690"
|
2023-03-06 12:39:43 +00:00
|
|
|
dependencies = [
|
|
|
|
"bytemuck",
|
|
|
|
"safe_arch",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "widestring"
|
2024-04-10 10:34:01 +00:00
|
|
|
version = "1.1.0"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-04-10 10:34:01 +00:00
|
|
|
checksum = "7219d36b6eac893fa81e84ebe06485e7dcbb616177469b142df14f1f4deb1311"
|
2022-07-16 21:49:35 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "winapi"
|
|
|
|
version = "0.3.9"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "5c839a674fcd7a98952e593242ea400abe93992746761e38641405d28b00f419"
|
|
|
|
dependencies = [
|
|
|
|
"winapi-i686-pc-windows-gnu",
|
|
|
|
"winapi-x86_64-pc-windows-gnu",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "winapi-i686-pc-windows-gnu"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "ac3b87c63620426dd9b991e5ce0329eff545bccbbb34f3be09ff6fb6ab51b7b6"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "winapi-util"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.1.9"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "cf221c93e13a30d793f7645a0e7762c55d169dbb0a49671918a2319d289b10bb"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-09-06 03:31:45 +00:00
|
|
|
"windows-sys 0.59.0",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "winapi-x86_64-pc-windows-gnu"
|
|
|
|
version = "0.4.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "712e227841d057c1ee1cd2fb22fa7e5a5461ae8e48fa2ca79ec42cfc1931183f"
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.51.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "ca229916c5ee38c2f2bc1e9d8f04df975b4bd93f9955dc69fabb5d91270045c9"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2024-05-21 12:07:32 +00:00
|
|
|
"windows-core 0.51.1",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-targets 0.48.5",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows"
|
2024-05-21 12:07:32 +00:00
|
|
|
version = "0.54.0"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-05-21 12:07:32 +00:00
|
|
|
checksum = "9252e5725dbed82865af151df558e754e4a3c2c30818359eb17465f1346a1b49"
|
2023-10-12 22:37:16 +00:00
|
|
|
dependencies = [
|
2024-05-21 12:07:32 +00:00
|
|
|
"windows-core 0.54.0",
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows-targets 0.52.6",
|
2023-10-12 22:37:16 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows-core"
|
|
|
|
version = "0.51.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "f1f8cf84f35d2db49a46868f947758c7a1138116f7fac3bc844f43ade1292e64"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-targets 0.48.5",
|
2023-04-08 08:44:28 +00:00
|
|
|
]
|
|
|
|
|
2024-05-21 12:07:32 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows-core"
|
|
|
|
version = "0.54.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "12661b9c89351d684a50a8a643ce5f608e20243b9fb84687800163429f161d65"
|
|
|
|
dependencies = [
|
|
|
|
"windows-result",
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows-targets 0.52.6",
|
2024-05-21 12:07:32 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows-result"
|
2024-07-18 19:18:08 +00:00
|
|
|
version = "0.1.2"
|
2024-05-21 12:07:32 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-18 19:18:08 +00:00
|
|
|
checksum = "5e383302e8ec8515204254685643de10811af0ed97ea37210dc26fb0032647f8"
|
2024-05-21 12:07:32 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows-targets 0.52.6",
|
2024-05-21 12:07:32 +00:00
|
|
|
]
|
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows-sys"
|
|
|
|
version = "0.48.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "677d2418bec65e3338edb076e806bc1ec15693c5d0104683f2efe857f61056a9"
|
|
|
|
dependencies = [
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-targets 0.48.5",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows-sys"
|
|
|
|
version = "0.52.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "282be5f36a8ce781fad8c8ae18fa3f9beff57ec1b52cb3de0789201425d9a33d"
|
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows-targets 0.52.6",
|
2022-10-20 05:05:36 +00:00
|
|
|
]
|
|
|
|
|
2024-09-05 21:03:23 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows-sys"
|
|
|
|
version = "0.59.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "1e38bc4d79ed67fd075bcc251a1c39b32a1776bbe92e5bef1f0bf1f8c531853b"
|
|
|
|
dependencies = [
|
|
|
|
"windows-targets 0.52.6",
|
|
|
|
]
|
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows-targets"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "9a2fa6e2155d7247be68c096456083145c183cbbbc2764150dda45a87197940c"
|
2023-04-08 08:44:28 +00:00
|
|
|
dependencies = [
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows_aarch64_gnullvm 0.48.5",
|
|
|
|
"windows_aarch64_msvc 0.48.5",
|
|
|
|
"windows_i686_gnu 0.48.5",
|
|
|
|
"windows_i686_msvc 0.48.5",
|
|
|
|
"windows_x86_64_gnu 0.48.5",
|
|
|
|
"windows_x86_64_gnullvm 0.48.5",
|
|
|
|
"windows_x86_64_msvc 0.48.5",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows-targets"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "9b724f72796e036ab90c1021d4780d4d3d648aca59e491e6b98e725b84e99973"
|
2023-12-06 09:51:40 +00:00
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows_aarch64_gnullvm 0.52.6",
|
|
|
|
"windows_aarch64_msvc 0.52.6",
|
|
|
|
"windows_i686_gnu 0.52.6",
|
2024-05-21 12:07:32 +00:00
|
|
|
"windows_i686_gnullvm",
|
2024-07-15 00:27:36 +00:00
|
|
|
"windows_i686_msvc 0.52.6",
|
|
|
|
"windows_x86_64_gnu 0.52.6",
|
|
|
|
"windows_x86_64_gnullvm 0.52.6",
|
|
|
|
"windows_x86_64_msvc 0.52.6",
|
2023-04-08 08:44:28 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows_aarch64_gnullvm"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "2b38e32f0abccf9987a4e3079dfb67dcd799fb61361e53e2882c3cbaf0d905d8"
|
2023-04-08 08:44:28 +00:00
|
|
|
|
2023-12-06 09:51:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_aarch64_gnullvm"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "32a4622180e7a0ec044bb555404c800bc9fd9ec262ec147edd5989ccd0c02cd3"
|
2023-12-06 09:51:40 +00:00
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_aarch64_msvc"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "dc35310971f3b2dbbf3f0690a219f40e2d9afcf64f9ab7cc1be722937c26b4bc"
|
2023-04-08 08:44:28 +00:00
|
|
|
|
2023-12-06 09:51:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_aarch64_msvc"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "09ec2a7bb152e2252b53fa7803150007879548bc709c039df7627cabbd05d469"
|
2023-12-06 09:51:40 +00:00
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_i686_gnu"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "a75915e7def60c94dcef72200b9a8e58e5091744960da64ec734a6c6e9b3743e"
|
2023-04-08 08:44:28 +00:00
|
|
|
|
2023-12-06 09:51:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_i686_gnu"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "8e9b5ad5ab802e97eb8e295ac6720e509ee4c243f69d781394014ebfe8bbfa0b"
|
2024-05-21 12:07:32 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "windows_i686_gnullvm"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2024-05-21 12:07:32 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "0eee52d38c090b3caa76c563b86c3a4bd71ef1a819287c19d586d7334ae8ed66"
|
2023-12-06 09:51:40 +00:00
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_i686_msvc"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "8f55c233f70c4b27f66c523580f78f1004e8b5a8b659e05a4eb49d4166cca406"
|
2023-04-08 08:44:28 +00:00
|
|
|
|
2023-12-06 09:51:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_i686_msvc"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "240948bc05c5e7c6dabba28bf89d89ffce3e303022809e73deaefe4f6ec56c66"
|
2023-12-06 09:51:40 +00:00
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_gnu"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "53d40abd2583d23e4718fddf1ebec84dbff8381c07cae67ff7768bbf19c6718e"
|
2023-04-08 08:44:28 +00:00
|
|
|
|
2023-12-06 09:51:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_gnu"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "147a5c80aabfbf0c7d901cb5895d1de30ef2907eb21fbbab29ca94c5b08b1a78"
|
2023-12-06 09:51:40 +00:00
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_gnullvm"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "0b7b52767868a23d5bab768e390dc5f5c55825b6d30b86c844ff2dc7414044cc"
|
2023-04-08 08:44:28 +00:00
|
|
|
|
2023-12-06 09:51:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_gnullvm"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "24d5b23dc417412679681396f2b49f3de8c1473deb516bd34410872eff51ed0d"
|
2023-12-06 09:51:40 +00:00
|
|
|
|
2023-04-08 08:44:28 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_msvc"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
version = "0.48.5"
|
2023-04-08 08:44:28 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
checksum = "ed94fce61571a4006852b7389a063ab983c02eb1bb37b47f8272ce92d06d9538"
|
2023-04-08 08:44:28 +00:00
|
|
|
|
2023-12-06 09:51:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "windows_x86_64_msvc"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.52.6"
|
2023-12-06 09:51:40 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "589f6da84c646204747d1270a2a5661ea66ed1cced2631d546fdfb155959f9ec"
|
2023-12-06 09:51:40 +00:00
|
|
|
|
2023-03-25 04:45:33 +00:00
|
|
|
[[package]]
|
|
|
|
name = "winnow"
|
2024-02-25 23:37:15 +00:00
|
|
|
version = "0.5.40"
|
2023-03-25 04:45:33 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-25 23:37:15 +00:00
|
|
|
checksum = "f593a95398737aeed53e489c785df13f3618e41dbcd6718c6addbf1395aa6876"
|
2023-03-25 04:45:33 +00:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
|
|
|
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
[[package]]
|
|
|
|
name = "winnow"
|
2024-08-01 08:06:09 +00:00
|
|
|
version = "0.6.18"
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-08-01 08:06:09 +00:00
|
|
|
checksum = "68a9bda4691f099d435ad181000724da8e5899daa10713c2d432552b9ccd3a6f"
|
2024-09-05 21:03:23 +00:00
|
|
|
dependencies = [
|
|
|
|
"memchr",
|
|
|
|
]
|
Ethereum Integration (#557)
* Clean up Ethereum
* Consistent contract address for deployed contracts
* Flesh out Router a bit
* Add a Deployer for DoS-less deployment
* Implement Router-finding
* Use CREATE2 helper present in ethers
* Move from CREATE2 to CREATE
Bit more streamlined for our use case.
* Document ethereum-serai
* Tidy tests a bit
* Test updateSeraiKey
* Use encodePacked for updateSeraiKey
* Take in the block hash to read state during
* Add a Sandbox contract to the Ethereum integration
* Add retrieval of transfers from Ethereum
* Add inInstruction function to the Router
* Augment our handling of InInstructions events with a check the transfer event also exists
* Have the Deployer error upon failed deployments
* Add --via-ir
* Make get_transaction test-only
We only used it to get transactions to confirm the resolution of Eventualities.
Eventualities need to be modularized. By introducing the dedicated
confirm_completion function, we remove the need for a non-test get_transaction
AND begin this modularization (by no longer explicitly grabbing a transaction
to check with).
* Modularize Eventuality
Almost fully-deprecates the Transaction trait for Completion. Replaces
Transaction ID with Claim.
* Modularize the Scheduler behind a trait
* Add an extremely basic account Scheduler
* Add nonce uses, key rotation to the account scheduler
* Only report the account Scheduler empty after transferring keys
Also ban payments to the branch/change/forward addresses.
* Make fns reliant on state test-only
* Start of an Ethereum integration for the processor
* Add a session to the Router to prevent updateSeraiKey replaying
This would only happen if an old key was rotated to again, which would require
n-of-n collusion (already ridiculous and a valid fault attributable event). It
just clarifies the formal arguments.
* Add a RouterCommand + SignMachine for producing it to coins/ethereum
* Ethereum which compiles
* Have branch/change/forward return an option
Also defines a UtxoNetwork extension trait for MAX_INPUTS.
* Make external_address exclusively a test fn
* Move the "account" scheduler to "smart contract"
* Remove ABI artifact
* Move refund/forward Plan creation into the Processor
We create forward Plans in the scan path, and need to know their exact fees in
the scan path. This requires adding a somewhat wonky shim_forward_plan method
so we can obtain a Plan equivalent to the actual forward Plan for fee reasons,
yet don't expect it to be the actual forward Plan (which may be distinct if
the Plan pulls from the global state, such as with a nonce).
Also properly types a Scheduler addendum such that the SC scheduler isn't
cramming the nonce to use into the N::Output type.
* Flesh out the Ethereum integration more
* Two commits ago, into the **Scheduler, not Processor
* Remove misc TODOs in SC Scheduler
* Add constructor to RouterCommandMachine
* RouterCommand read, pairing with the prior added write
* Further add serialization methods
* Have the Router's key included with the InInstruction
This does not use the key at the time of the event. This uses the key at the
end of the block for the event. Its much simpler than getting the full event
streams for each, checking when they interlace.
This does not read the state. Every block, this makes a request for every
single key update and simply chooses the last one. This allows pruning state,
only keeping the event tree. Ideally, we'd also introduce a cache to reduce the
cost of the filter (small in events yielded, long in blocks searched).
Since Serai doesn't have any forwarding TXs, nor Branches, nor change, all of
our Plans should solely have payments out, and there's no expectation of a Plan
being made under one key broken by it being received by another key.
* Add read/write to InInstruction
* Abstract the ABI for Call/OutInstruction in ethereum-serai
* Fill out signable_transaction for Ethereum
* Move ethereum-serai to alloy
Resolves #331.
* Use the opaque sol macro instead of generated files
* Move the processor over to the now-alloy-based ethereum-serai
* Use the ecrecover provided by alloy
* Have the SC use nonce for rotation, not session (an independent nonce which wasn't synchronized)
* Always use the latest keys for SC scheduled plans
* get_eventuality_completions for Ethereum
* Finish fleshing out the processor Ethereum integration as needed for serai-processor tests
This doesn't not support any actual deployments, not even the ones simulated by
serai-processor-docker-tests.
* Add alloy-simple-request-transport to the GH workflows
* cargo update
* Clarify a few comments and make one check more robust
* Use a string for 27.0 in .github
* Remove optional from no-longer-optional dependencies in processor
* Add alloy to git deny exception
* Fix no longer optional specification in processor's binaries feature
* Use a version of foundry from 2024
* Correct fetching Bitcoin TXs in the processor docker tests
* Update rustls to resolve RUSTSEC warnings
* Use the monthly nightly foundry, not the deleted daily nightly
2024-04-21 10:02:12 +00:00
|
|
|
|
2023-06-22 10:25:30 +00:00
|
|
|
[[package]]
|
|
|
|
name = "winreg"
|
|
|
|
version = "0.50.0"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "524e57b2c537c0f9b1e69f1965311ec12182b4122e45035b1508cd24d2adadb1"
|
|
|
|
dependencies = [
|
|
|
|
"cfg-if",
|
2023-12-06 09:51:40 +00:00
|
|
|
"windows-sys 0.48.0",
|
2023-06-22 10:25:30 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "wyz"
|
2022-11-21 07:23:38 +00:00
|
|
|
version = "0.5.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2022-11-21 07:23:38 +00:00
|
|
|
checksum = "05f360fc0b24296329c78fda852a1e9ae82de9cf7b27dae4b7f62f118f77b9ed"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"tap",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "x25519-dalek"
|
2024-02-09 07:48:44 +00:00
|
|
|
version = "2.0.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-02-09 07:48:44 +00:00
|
|
|
checksum = "c7e468321c81fb07fa7f4c636c3972b9100f0346e5b6a9f2bd0603a52f7ed277"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
2023-10-16 19:07:39 +00:00
|
|
|
"curve25519-dalek",
|
|
|
|
"rand_core",
|
|
|
|
"serde",
|
2022-07-16 21:49:35 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "x509-parser"
|
|
|
|
version = "0.15.1"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "7069fba5b66b9193bd2c5d3d4ff12b839118f6bcbef5328efafafb5395cf63da"
|
|
|
|
dependencies = [
|
|
|
|
"asn1-rs",
|
|
|
|
"data-encoding",
|
|
|
|
"der-parser",
|
|
|
|
"lazy_static",
|
|
|
|
"nom",
|
|
|
|
"oid-registry",
|
|
|
|
"rusticata-macros",
|
|
|
|
"thiserror",
|
2023-09-12 11:47:03 +00:00
|
|
|
"time",
|
2023-08-25 03:55:47 +00:00
|
|
|
]
|
|
|
|
|
2023-10-19 04:27:21 +00:00
|
|
|
[[package]]
|
|
|
|
name = "xml-rs"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "0.8.21"
|
2023-10-19 04:27:21 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "539a77ee7c0de333dcc6da69b177380a0b81e0dacfa4f7344c465a36871ee601"
|
2023-10-19 04:27:21 +00:00
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "xmltree"
|
|
|
|
version = "0.10.3"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "d7d8a75eaf6557bb84a65ace8609883db44a29951042ada9b393151532e41fcb"
|
|
|
|
dependencies = [
|
|
|
|
"xml-rs",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "yamux"
|
2023-12-03 05:04:59 +00:00
|
|
|
version = "0.12.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-12-03 05:04:59 +00:00
|
|
|
checksum = "9ed0164ae619f2dc144909a9f082187ebb5893693d8c0196e8085283ccd4b776"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"futures",
|
|
|
|
"log",
|
|
|
|
"nohash-hasher",
|
2024-06-13 19:57:08 +00:00
|
|
|
"parking_lot 0.12.3",
|
2023-08-15 09:39:23 +00:00
|
|
|
"pin-project",
|
cargo update
Achieves three notable updates.
1) Resolves RUSTSEC-2022-0093 by updating libp2p-identity.
2) Removes 3 old rand crates via updating ed25519-dalek (a dependency of
libp2p-identity).
3) Sets serde_derive to 1.0.171 via updating to time 0.3.26 which pins at up to
1.0.171.
The last one is the most important. The former two are niceties.
serde_derive, since 1.0.171, ships a non-reproducible binary blob in what's a
complete compromise of supply chain security. This is done in order to reduce
compile times, yet also for the maintainer of serde (dtolnay) to leverage
serde's position as the 8th most downloaded crate to attempt to force changes
to the Rust build pipeline.
While dtolnay's contributions to Rust are respectable, being behind syn, quote,
and proc-macro2 (the top three crates by downloads), along with thiserror,
anyhow, async-trait, and more (I believe also being part of the Rust project),
they have unfortunately decided to refuse to listen to the community on this
issue (or even engage with counter-commentary). Given their political agenda
they seem to try to be accomplishing with force, I'd go as far as to call their
actions terroristic (as they're using the threat of the binary blob as
justification for cargo to ship 'proper' support for binary blobs).
This is arguably representative of dtolnay's past work on watt. watt was a wasm
interpreter to execute a pre-compiled proc macro. This would save the compile
time of proc macros, yet sandbox it so a full binary did not have to be run.
Unfortunately, watt (while decreasing compile times) fails to be a valid
solution to supply chain security (without massive ecosystem changes). It never
implemented reproducible builds for its wasm blobs, and a malicious wasm blob
could still fundamentally compromise a project. The only solution for an end
user to achieve a secure pipeline would be to locally build the project,
verifying the blob aligns, yet doing so would negate all advantages of the
blob.
dtolnay also seems to be giving up their role as a FOSS maintainer given that
serde no longer works in several environments. While FOSS maintainers are not
required to never implement breaking changes, the version number is still 1.0.
While FOSS maintainers are not required to follow semver, releasing a very
notable breaking change *without a new version number* in an ecosystem which
*does follow semver*, then refusing to acknowledge bugs as bugs with their work
does meet my personal definition of "not actively maintaining their existing
work". Maintenance would be to fix bugs, not introduce and ignore.
For now, serde > 1.0.171 has been banned. In the future, we may host a fork
without the blobs (yet with the patches). It may be necessary to ban all of
dtolnay's maintained crates, if they continue to force their agenda as such,
yet I hope this may be resolved within the next week or so.
Sources:
https://github.com/serde-rs/serde/issues/2538 - Binary blob discussion
This includes several reports of various workflows being broken.
https://github.com/serde-rs/serde/issues/2538#issuecomment-1682519944
dtolnay commenting that security should be resolved via Rust toolchain edits,
not via their own work being secure. This is why I say they're trying to
leverage serde in a political game.
https://github.com/serde-rs/serde/issues/2526 - Usage via git broken
dtolnay explicitly asks the submitting user if they'd be willing to advocate
for changes to Rust rather than actually fix the issue they created. This is
further political arm wrestling.
https://github.com/serde-rs/serde/issues/2530 - Usage via Bazel broken
https://github.com/serde-rs/serde/issues/2575 - Unverifiable binary blob
https://github.com/dtolnay/watt - dtolnay's prior work on precompilation
2023-08-19 05:14:01 +00:00
|
|
|
"rand",
|
2022-07-16 21:49:35 +00:00
|
|
|
"static_assertions",
|
|
|
|
]
|
|
|
|
|
2023-08-25 03:55:47 +00:00
|
|
|
[[package]]
|
|
|
|
name = "yasna"
|
|
|
|
version = "0.5.2"
|
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
|
|
|
checksum = "e17bb3549cc1321ae1296b9cdc2698e2b6cb1992adfa19a8c72e5b7a738f44cd"
|
|
|
|
dependencies = [
|
2023-09-12 11:47:03 +00:00
|
|
|
"time",
|
2023-08-25 03:55:47 +00:00
|
|
|
]
|
|
|
|
|
2022-11-11 05:34:40 +00:00
|
|
|
[[package]]
|
|
|
|
name = "zalloc"
|
|
|
|
version = "0.1.0"
|
|
|
|
dependencies = [
|
2024-06-02 01:46:47 +00:00
|
|
|
"rustversion",
|
2022-11-11 05:34:40 +00:00
|
|
|
"zeroize",
|
|
|
|
]
|
|
|
|
|
2023-10-24 08:03:51 +00:00
|
|
|
[[package]]
|
|
|
|
name = "zerocopy"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.7.35"
|
2023-10-24 08:03:51 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "1b9b4fd18abc82b8136838da5d50bae7bdea537c574d8dc1a34ed098d6c166f0"
|
2023-10-24 08:03:51 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"byteorder",
|
2023-10-24 08:03:51 +00:00
|
|
|
"zerocopy-derive",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zerocopy-derive"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.7.35"
|
2023-10-24 08:03:51 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "fa4f8080344d4671fb4e831a13ad1e68092748387dfc4f55e356242fae12ce3e"
|
2023-10-24 08:03:51 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2023-10-24 08:03:51 +00:00
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "zeroize"
|
2024-06-13 19:57:08 +00:00
|
|
|
version = "1.8.1"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-06-13 19:57:08 +00:00
|
|
|
checksum = "ced3678a2879b30306d323f4542626697a464a97c0a07c9aebf7ebca65cd4dde"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"zeroize_derive",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zeroize_derive"
|
2023-03-31 06:34:52 +00:00
|
|
|
version = "1.4.2"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-03-31 06:34:52 +00:00
|
|
|
checksum = "ce36e65b0d2999d2aafac989fb249189a141aee1f53c612c1f37d72631959f69"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"proc-macro2",
|
|
|
|
"quote",
|
2024-09-05 21:03:23 +00:00
|
|
|
"syn 2.0.77",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zstd"
|
|
|
|
version = "0.11.2+zstd.1.5.2"
|
|
|
|
dependencies = [
|
2024-07-15 00:27:36 +00:00
|
|
|
"zstd 0.13.2",
|
2023-04-09 06:31:10 +00:00
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zstd"
|
2023-07-24 08:54:13 +00:00
|
|
|
version = "0.12.4"
|
2023-04-09 06:31:10 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-24 08:54:13 +00:00
|
|
|
checksum = "1a27595e173641171fc74a1232b7b1c7a7cb6e18222c11e9dfb9888fa424c53c"
|
2023-04-09 06:31:10 +00:00
|
|
|
dependencies = [
|
2024-03-21 01:53:57 +00:00
|
|
|
"zstd-safe 6.0.6",
|
|
|
|
]
|
|
|
|
|
|
|
|
[[package]]
|
|
|
|
name = "zstd"
|
2024-07-15 00:27:36 +00:00
|
|
|
version = "0.13.2"
|
2024-03-21 01:53:57 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-07-15 00:27:36 +00:00
|
|
|
checksum = "fcf2b778a664581e31e389454a7072dab1647606d44f7feea22cd5abb9c9f3f9"
|
2024-03-21 01:53:57 +00:00
|
|
|
dependencies = [
|
2024-09-05 21:03:23 +00:00
|
|
|
"zstd-safe 7.2.1",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|
|
|
|
|
2023-04-09 06:31:10 +00:00
|
|
|
[[package]]
|
|
|
|
name = "zstd-safe"
|
2023-07-24 08:54:13 +00:00
|
|
|
version = "6.0.6"
|
2023-04-09 06:31:10 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2023-07-24 08:54:13 +00:00
|
|
|
checksum = "ee98ffd0b48ee95e6c5168188e44a54550b1564d9d530ee21d5f0eaed1069581"
|
2023-04-09 06:31:10 +00:00
|
|
|
dependencies = [
|
|
|
|
"libc",
|
|
|
|
"zstd-sys",
|
|
|
|
]
|
|
|
|
|
2024-03-21 01:53:57 +00:00
|
|
|
[[package]]
|
|
|
|
name = "zstd-safe"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "7.2.1"
|
2024-03-21 01:53:57 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "54a3ab4db68cea366acc5c897c7b4d4d1b8994a9cd6e6f841f8964566a419059"
|
2024-03-21 01:53:57 +00:00
|
|
|
dependencies = [
|
|
|
|
"zstd-sys",
|
|
|
|
]
|
|
|
|
|
2022-07-16 21:49:35 +00:00
|
|
|
[[package]]
|
|
|
|
name = "zstd-sys"
|
2024-09-05 21:03:23 +00:00
|
|
|
version = "2.0.13+zstd.1.5.6"
|
2022-07-16 21:49:35 +00:00
|
|
|
source = "registry+https://github.com/rust-lang/crates.io-index"
|
2024-09-05 21:03:23 +00:00
|
|
|
checksum = "38ff0f21cfee8f97d94cef41359e0c89aa6113028ab0291aa8ca0038995a95aa"
|
2022-07-16 21:49:35 +00:00
|
|
|
dependencies = [
|
|
|
|
"cc",
|
2023-01-16 15:42:31 +00:00
|
|
|
"pkg-config",
|
2022-07-16 21:49:35 +00:00
|
|
|
]
|