I see that it is not possible to burn two different tokens with the same badge in a authorize block. Maybe making mint and burn methods accept a reference to a BucketRef would solve the issue ?

pub fn change_supply(&mut self, badge_to_burn: Bucket) {
    self.minter_badge.authorize(|badge| {
        badge_to_burn.burn(badge);
        // todo: error here: use of moved resource: badge
        self.token_vault.take(100).burn(badge);
    });
}

This PR adds ValidatedProofs as a language level concept to Scrypto. With this PR, a Proof would have two main methods:

• validate_proof: Takes in a ResourceAddress and validates that the proof has a matching resource address.
• unsafe_skip_proof_validation: Takes no arguments and simply skips the validation of the resource address.

All of the methods that were previously available on Proofs are now available on ValidatedProofs.

This is an implementation of the ideas I put forward in #285.

The high level summary: Caller's can optionally use an AuthZone which will be visible to Callee's. The callee's can optionally indicate the caller proofs they want access to by simply using the AccessRules as they already do. When both sides agree, authorization and follow-on business logic (ie. based on a Proof of NonFungableData) works seamlessly. The caller can specify their "pass by intent" by using an AuthZone to group their Proofs instead of seperate args. This is kind of like varargs for Proofs.

There are 2 complementary features that work together.

1. AuthZones now live in a stack so actors can push the current one back putting a new empty AuthZone in it's place, or undo that. (instructions StartAuthZone, EndAuthZone and API ComponentAuthZone::start() and ComponentAuthZone::end())
2. Components can access the caller's AuthZone proofs with the same AuthZone API (not push/pop) using CallerAuthZone::create_proof* as they would have used ComponentAuthZone

These features are joined up forming a nice usable enhancement but with safety restrictions:

1. The CallerAuthZone is at most a "shadow" of only the top AuthZone in the stack, so it's fully controlled by the caller.
2. Which proofs are allowed in to the shadow must be explicitly defined by the callee. This is done by using the same AccessRules they already use to protect method calls. When those HardAuthRules are checked, the shadow AuthZone is built up based on the matches which were already being visited. The only overhead is cloning the Proofs. So nothing happens on "allow_all", only explicit rule matches.
3. And finally, if the caller is only using the default AuthZone, ie they've never done a single StartAuthZone instruction or AuthZone::start() to push a new AuthZone on the stack, then the shadow calculation does not happen at all, leaving the CallerAuthZone empty. So everything is completely opt-in by the caller and protects their tx signing virtual badges. Even the performance hit for the clones only happens when needed.

Would love feedback on the idea now that you can see it more concretely @russellharvey . I think the implementation is pretty straight forward, though there are a few places I still had questions. Also I'm not sure I love the vocabulary I used everywhere, start/end, caller, shadow, etc. A second opinion on if that all makes sense would be nice. Maybe @iamyulong or @talekhinezh can take a look at this PR when they have time (I realize there are other priorities). (See the "FIXMEs for some specific questions"). I also think adding try_create_proofs* APIs to return Option instead of panic would be really helpful to enable more use cases. I'd be willing to add those.

I don't expect this to be merged as is, but it is feature complete with tests and in decent shape. This is mostly meant to move that discussion forward and was a good way for me to dig into some of the Scrypto internals. If it's never accepted that's fine but I think there's room to iterate on this idea for sure at leaset. It was a good learning experience for me either way. I realize some of the SNode and wasm stuff is changing, and at minimum this PR should probably be rebased and fixed up for the develop branch so it certainly needs a little care before it's ready too.

My use case for wanting this is honestly not fully flushed out. But the friction for me came when I was trying to build up a more complex authorization model and interacting with multiple components. In this case I wanted some components to return badges to the caller and then have the caller use them against other components without having to specify them (because they might not know the resource address or ids if another component is in charge of authentication/authorization for a group of components). And of course they would be NFT badges. So this type of thing isn't possible without this PR because NFT badges have to be passed by intent right now so the callee can access the data.

Decimal::powi(&self, exp:i32) -> Decimal function is now implemented with approximation. This solution will also work once we make Decimal::SCALE mutable.

It seems we don't have the flexibility to change the lib name inside the Cargo.toml file. Changing it to anything other than out causes issues with testing and compiling. Also when docs are generated, they are labelled as out too.

Would it be possible to update the following code to allow the lib name to default to maybe CARGO_BIN_NAME to we can at least define a name we would like.

I believe this is the location of the file that needs to be updated: https://github.com/radixdlt/radixdlt-scrypto/blob/ce6b70929bf487a2cc6779133ddbbc1981893624/scrypto/src/lib.rs

I think we can do something like the following:

#[macro_export]
macro_rules! include_code {
    () => {
        include_bytes!(concat!(
            env!("CARGO_MANIFEST_DIR"),
            format!("/target/wasm32-unknown-unknown/release/{}.wasm", env!("CARGO_BIN_NAME") )
        ))
    };
    ($package_dir: expr) => {
        include_bytes!(concat!(
            $package_dir,
            format!("/target/wasm32-unknown-unknown/release/{}.wasm", env!("CARGO_BIN_NAME"))
        ))
    };
}

This PR solves overflow errors in the powi function. The following code would overflow at every line involving powi:

    #[test]
    fn test_powi_max_decimal() {
        let _max_bug = Decimal::MAX.powi(1);
        let _max_sqrt = Decimal::MAX.sqrt().unwrap();
        let _max_cbrt = Decimal::MAX.cbrt();
        let _max_dec_2 = _max_sqrt.powi(2);
        let _max_dec_3 = _max_cbrt.powi(3);
    }
    ```
    
    The PR also changes integer used in root function of `Decimal` and `PreciseDecimal` to tighter integers (I384 and I768 as suggested by @r001)

(from discussion on Discord)

Badges give access rights to the called method, and it would be able to do anything with it (presenting it) on the behalf of the caller... It can be useful, but also it is a lot of trust.

Maybe it could be made explicit whether a token can be re-presented by a component to other components.

I can think of scenarios where that such behavior would be really useful. A travel booking component might require me to present my KYC/identity badge but would then also present it to the airline, hotel and rental car booking components, which have a legitimate interest in knowing my identity.

On the other hand I would not want a misbehaving "travel booking" component taking out a loan somewhere using my identity.

Proposal:

The 1st component could specify to which other components it will re-present the badge so the user can check that before signing the transaction

It could be something similar to the #[auth(badge_ref)] decoration on a method.

#[auth(badge_ref)]
#[present_to(a1b2...7890 and c3d4...0987)]
pub fn do_something() {
    ...
}

Or using the same auth decorator:

#[auth(badge_ref -> a1b2...7890 and c3d4...0987)]
pub fn do_something() {
    ...
}

(the component addresses are abbreviated above, they should be the complete address)

Then:

Option 1: the transaction could include to which other components the badge is allowed to be presented

Option 2: the Radix Engine logic could control that by itself: once a function with that "decoration" is called, the marked badges for that function can only pre presented to the defined components.

I am trying to remove the floating part of a Decimal but can't find an easy way to do it (other than transforming to String and removing the floating part from there).

This might not be the best way to do it but I think it is useful to only have to specify "XRD" when sending buckets to functions and methods instead of the full address.

You need to know if you're encoding a payload or a payload-part. Typically this is obvious, the main caveat is where we pull together multiple sub-parts into a larger struct - notably Transaction Manifest args and Non Fungible Data.

In these cases, they're encoded as a complete struct, without a separate prefix byte for each argument/field - this felt like the only real correct approach.

I also had to do some hand-cranked WASM which was fun :).

The tests aren't running on this PR :( - but I've run them locally and they pass.

Breaking changes

• SBOR - Basic payloads start with 0x5b (think [5b]or) and scrypto payloads start with 0x5c (think [5c]rypto).

Here is an example I have tested withdrawing an NFT when it wasn't updated and when it was changed:

Transaction manifest:

CALL_METHOD ComponentAddress("account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx") "lock_fee" Decimal("100");
CALL_METHOD ComponentAddress("account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx") "withdraw" ResourceAddress("resource_sim1qqv26c2pgd0v36qg6rp9uunj8rat09s0aa3kqdalahtsysyhh4");
TAKE_FROM_WORKTOP ResourceAddress("resource_sim1qqv26c2pgd0v36qg6rp9uunj8rat09s0aa3kqdalahtsysyhh4") Bucket("token");
CALL_METHOD_WITH_ALL_RESOURCES ComponentAddress("account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx") "deposit_batch";

Non-updated:

$ resim run withdraw.rtm
Transaction Status: COMMITTED SUCCESS
Transaction Fee: 0.93161 XRD burned, 0.0465805 XRD tipped to validators
Cost Units: 4294967295 limit, 931610 consumed, 0.000001 XRD per cost unit
Logs: 0
Instructions:
├─ CallMethod { component_address: account_sim1qw9j97utxsjnxcs2lus4kqm8lu84z5ygpzd2gkn5dljs6ncf0k, method_name: "lock_fee", call_data: Struct(Decimal("100")) }
├─ CallMethod { component_address: account_sim1qw9j97utxsjnxcs2lus4kqm8lu84z5ygpzd2gkn5dljs6ncf0k, method_name: "withdraw", call_data: Struct(ResourceAddress("resource_sim1qzhwqhlvelrdjqnd0xp0hd8tfdjqsxkqshzvkylkrmhqydgdur")) }
├─ TakeFromWorktop { resource_address: resource_sim1qzhwqhlvelrdjqnd0xp0hd8tfdjqsxkqshzvkylkrmhqydgdur }
└─ CallMethodWithAllResources { component_address: account_sim1qw9j97utxsjnxcs2lus4kqm8lu84z5ygpzd2gkn5dljs6ncf0k, method: "deposit_batch" }
Instruction Outputs:
├─ ()
├─ Bucket(1024u32)
├─ Bucket(512u32)
└─ ()
New Entities: 0

Updated:

$ resim run withdraw.rtm
Transaction Status: COMMITTED FAILURE: ApplicationError(VaultError(ResourceContainerError(InsufficientBalance)))
Transaction Fee: 0.580059 XRD burned, 0.02900295 XRD tipped to validators
Cost Units: 4294967295 limit, 580059 consumed, 0.000001 XRD per cost unit
Logs: 0
Instructions:
├─ CallMethod { component_address: account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx, method_name: "lock_fee", call_data: Struct(Decimal("100")) }
├─ CallMethod { component_address: account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx, method_name: "withdraw", call_data: Struct(ResourceAddress("resource_sim1qqv26c2pgd0v36qg6rp9uunj8rat09s0aa3kqdalahtsysyhh4")) }
├─ TakeFromWorktop { resource_address: resource_sim1qqv26c2pgd0v36qg6rp9uunj8rat09s0aa3kqdalahtsysyhh4 }
└─ CallMethodWithAllResources { component_address: account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx, method: "deposit_batch" }
New Entities: 0

Account state:

$ resim show account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx
Component: account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx
Blueprint: { package_address: package_sim1qyqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqpsuluv44, blueprint_name: "Account" }
Authorization
├─ "balance" => AllowAll
├─ "deposit_batch" => AllowAll
└─ "deposit" => AllowAll
State: Struct(KeyValueStore("0444f6d698277561d2a2c7b1e1be4a06066f729cb00154461400eadb8d5ab71802040000"))
Key Value Store: account_sim1qduh9kkxlasynyywer0hl5zdculasfwz9z67qtx6592q9tadqx(0444f6d698277561d2a2c7b1e1be4a06066f729cb00154461400eadb8d5ab718, 1026)
├─ ResourceAddress("resource_sim1qr0700ctxkvf8a0t3k953klq8ehlrmek8g5036v9kmvswyynme") => Vault("f8da93c15b094676798b223c77bbf1c1a424b3853410475d4eb4cab5072a334d09040000")
├─ ResourceAddress("resource_sim1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqzqu57yag") => Vault("0444f6d698277561d2a2c7b1e1be4a06066f729cb00154461400eadb8d5ab71804040000")
└─ ResourceAddress("resource_sim1qqv26c2pgd0v36qg6rp9uunj8rat09s0aa3kqdalahtsysyhh4") => Vault("9214a0eb3ec0d2d05ae9f8c29131ad578f0efa125a849e054929e5f9c460cf660a040000")
Resources:
├─ { amount: 0, resource address: resource_sim1qr0700ctxkvf8a0t3k953klq8ehlrmek8g5036v9kmvswyynme, name: "token" }
├─ { amount: 999994.7954986, resource address: resource_sim1qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqzqu57yag, name: "Radix", symbol: "XRD" }
└─ { amount: 1, resource address: resource_sim1qqv26c2pgd0v36qg6rp9uunj8rat09s0aa3kqdalahtsysyhh4, name: "User Badge" }
   └─ NonFungible { id: NonFungibleId("3007100000007f5f63054c736247c827a93d5ca204d7"), immutable_data: Struct(), mutable_data: Struct(6535u64, Decimal("943465")) }

There's a clear bug when trying to withdraw an NFT after it's data have been updated.

Removed NonFungibleAddress from the value model, with developer facing inteface untouched:

• In Manifest, NonFungibleAddress("address", 1u32) is still supported;
• Scrypto Lib abstraction NonFungibleAddress stays;
• Scrypto schema type NonFungibleAddress stays;
• Non-fungible address based auth continues to work.

Removed ManifestBucket/ManifestProof/ManifestExpression from Scrypto schema.

• Add concept of "native packages" such that every invocation (scrypto+native) has a package identifier associated with it, imilar to the Rust "crate" concept.
• Add virtual "package token" which is included as a virtual proof in the AuthZone, one may now only allow certain functions/methods to be called only if in the same package, similar to Rust 'pub(crate)' visibility flags.

• Separated ManifestBucket and ManifestProof from Scrypto bucket/proof ("own")
• Changed ManifestExpression to an enum
• Split IDAllocator into ManifestIdAllocator and (Runtime)IdAllocator
• Overhauled Scrypto custom type codec (variant length)