fuel
April 7, 2023, 3:36pm
1
Hi, guys on fuels-rs v0.38.1 was possible to get the predicted address using predicate.address().into(), but on v0.39 I have an error
sarah
April 7, 2023, 4:29pm
2
predicate.address().into() still works for me on the predicate type with v0.39. This looks like it might be related to you using a LimitOrdersPredicate type that doesn’t implement this method.
sarah
April 7, 2023, 4:40pm
3
For your reference, you can see the full breaking changes here:
FuelLabs:master ← FuelLabs:Salka1988/predicate_pay_transaction
opened 12:58AM - 03 Feb 23 UTC
The PR aims to enable predicates to be used as wallets, allowing payments and tr… ansactions to be made with them. The first step taken in this direction was to modify the `predicate_bindings` function so that it returns the `Predicate` data type, which will be further used as we use the wallet.
```rust
MyPredicateHandler::load_from(
"../../packages/fuels/tests/predicates/predicate_signatures/out/debug/predicate_signatures.bin",
).set_data(signatures).get_predicate();
```
This code loads the predicate .bin together with the signature for unlocking the predicate and returns the `Predicate` data type, which can be used as a wallet for making transactions, etc.
In addition, I added a new public trait called `Account`, which includes a group of functions common to both wallets and predicates. Any function that receives `T: Account` as a parameter can use these common functions.
```rust
pub trait Account: std::fmt::Debug + Send + Sync { ... }
```
Predicates that have dynamic data as input require special handling because the underlying pointer needs to be adjusted with the right offset for the actual data. To resolve the pointers of a given predicate input, we need to know all the previous tx inputs. The problem here is that the transaction can be modified at any point which can potentially invalidate the offsets.
`fuels_types::Input` is introduced to circumvent this. For predicates, it stores the relevant resource and the predicate data as `UnresolvedBytes`.
Some of `ScriptTransaction`s methods have been moved to the new `ScriptTransactionBuilder`. The idea is that the builder works on our input types and still allows for modifications. Once `build()` is called, the predicate data is resolved for all predicate inputs and the resulting `ScriptTransaction` doesn't allow for further changes to the inputs.
Some caveats:
- We currently don't have a native `Output` type. Should we implement as a thin wrapper for the sake of consistency?
- `UnresolvedBytes` has been moved to fuels_types to avoid cyclic deps. This also means that `Data` moved with it. Since
`Data` is used for parts of the abigen, we had to make it public. Is there a better alternative?
- To deduplicate significant amounts of code, `get_asset_inputs_for_amount` accepts `witness_index` as a parameter. For predicates we just ignore it in the implementation but overall it doesn't make sense in the context of predicates.
closes #809
system
April 28, 2023, 12:40pm
4
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.
