Explore
Connect with communities and discover new ideas.
Communities
Supra connect multiple innovations into architecture that vertically integrates MultiVM smart contract support and native services: such as price feed oracles, on-chain randomness, cross-chain communications, and automation.
Top postsTop members- 58
- 47
- 45
Cartesi is a layer-2 platform for scalable decentralized apps. It combines Linux OS and blockchain infrastructure, which allows DApps to be developed in familiar programming languages
Top postsTop members- 163
- 109
- 98
Sui Name Service is building the next-generation of Identity Services on the Sui blockchain
Top postsTop members- 159
- 148
- 136
- Top members
- 53
- 25
- 16
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.
Top posts- Top postsTop members
- 15
- 15
- 10
- Top postsTop members
- 10
- Top postsTop members
- 11
- 10
- 8
- Top postsTop members
- 10
- 10
- Top postsTop members
- 10
- Top postsTop members
- 10
- Top postsTop members
- 10
- Top postsTop members
- Top postsTop members
- Top postsTop members
- Top postsTop members
- Top postsTop members
- Top postsTop members
- Top postsTop members
- Top postsTop members
- Top postsTop members
- 136
- 122
- 110
- Top postsTop members
Bounty
Future of Blockchain in Global Governance
Blockchain technology promises significant advancements in global governance by enhancing transparency, accountability, and efficiency. As governments and international organizations explore its potential, several key applications emerge: Decentralized Voting: Utilizing blockchain for elections can mitigate fraud, protect voter privacy, and ensure transparency. Immutability of records provides an auditable trail, boosting public trust. Supply Chain Transparency: Governments can use blockchain to track products, ensuring safety and compliance. This is particularly crucial for food safety, pharmaceuticals, and environmental regulations, where verification of sources is paramount. Data Sovereignty: Blockchain can empower citizens by granting them control over their personal data, facilitating the secure sharing of information with governments while reducing data breaches and fraud risks. These applications point to a more transparent and accountable global governance structure, leveraging blockchain’s unique features to enhance citizen engagement and trust in governmental processes .
-12- +2ForSupraFeb 18, 2025
How is blockchain influencing the real estate market?
How is blockchain influencing the real estate market?
10 - +3ForSuiFeb 18, 2025
How is blockchain impacting education and credentialing?
How is blockchain impacting education and credentialing?
02
Newest
ForSupraSep 04, 2025Evolution of Digital Ownership
Non-Fungible Tokens (NFTs) have sparked a revolution in how digital art, music, and collectibles are owned and traded. This article covers the technology behind NFTs, their cultural impact, new business models they enable, and the environmental concerns surrounding their blockchain implementation.
00Best practices for handling API rate limits in production?
I'm working on a web application that makes frequent API calls to a third-party service, and I'm starting to hit rate limits during peak usage times. Current Situation: ~500 requests per minute during busy periods Getting 429 errors about 10-15% of the time Using a simple retry mechanism with exponential backoff What I've Tried: Implemented basic caching for repeated requests Added request queuing with delays Set up monitoring for rate limit headers The retry logic helps, but I'm wondering if there are better architectural patterns I should consider. Has anyone dealt with similar issues at scale? Any suggestions for: More sophisticated rate limiting strategies? Better caching approaches? Monitoring tools you'd recommend? Thanks in advance for any insights!
01- ForSupraSep 04, 2025
Best practices for handling API rate limits in production?
I'm working on a web application that makes frequent API calls to a third-party service, and I'm starting to hit rate limits during peak usage times. Current Situation: ~500 requests per minute during busy periods Getting 429 errors about 10-15% of the time Using a simple retry mechanism with exponential backoff What I've Tried: Implemented basic caching for repeated requests Added request queuing with delays Set up monitoring for rate limit headers The retry logic helps, but I'm wondering if there are better architectural patterns I should consider. Has anyone dealt with similar issues at scale? Any suggestions for: More sophisticated rate limiting strategies? Better caching approaches? Monitoring tools you'd recommend? Thanks in advance for any insights!
00
Unanswered
- ForSupraSep 04, 2025
Evolution of Digital Ownership
Non-Fungible Tokens (NFTs) have sparked a revolution in how digital art, music, and collectibles are owned and traded. This article covers the technology behind NFTs, their cultural impact, new business models they enable, and the environmental concerns surrounding their blockchain implementation.
00 - ForSupraSep 04, 2025
Best practices for handling API rate limits in production?
I'm working on a web application that makes frequent API calls to a third-party service, and I'm starting to hit rate limits during peak usage times. Current Situation: ~500 requests per minute during busy periods Getting 429 errors about 10-15% of the time Using a simple retry mechanism with exponential backoff What I've Tried: Implemented basic caching for repeated requests Added request queuing with delays Set up monitoring for rate limit headers The retry logic helps, but I'm wondering if there are better architectural patterns I should consider. Has anyone dealt with similar issues at scale? Any suggestions for: More sophisticated rate limiting strategies? Better caching approaches? Monitoring tools you'd recommend? Thanks in advance for any insights!
00 - ForSupraSep 03, 2025
The New Governance Model
DAOs represent a novel way of organizing communities and businesses using blockchain-based smart contracts. This article explains how DAOs operate, their benefits and challenges, and real-world examples that demonstrate new forms of decentralized decision-making and resource management.
00
Trending
Programmable Transaction Blocks
Programmable transaction blocks are a group of commands that complete a transaction on Sui. On Sui, a transaction is more than a basic record of the flow of assets. Transactions on Sui are composed of a number of commands that execute on inputs to define the result of the transaction. Termed programmable transaction blocks (PTBs), these groups of commands define all user transactions on Sui. PTBs allow a user to call multiple Move functions, manage their objects, and manage their coins in a single transaction--without publishing a new Move package. Designed with automation and transaction builders in mind, PTBs are a lightweight and flexible way of generating transactions. More intricate programming patterns, such as loops, are not supported, however, and in those cases you must publish a new Move package. As mentioned, each PTB is comprised of individual transaction commands (sometimes referred to simply as transactions or commands). Each transaction command executes in order, and you can use the results from one transaction command in any subsequent transaction command. The effects, specifically object modifications or transfers, of all transaction commands in a block are applied atomically at the end of the transaction. If one transaction command fails, the entire block fails and no effects from the commands are applied. A PTB can perform up to 1,024 unique operations in a single execution, whereas transactions on traditional blockchains would require 1,024 individual executions to accomplish the same result. The structure also promotes cheaper gas fees. The cost of facilitating individual transactions is always more than the cost of those same transactions blocked together in a PTB. The remainder of this topic covers the semantics of the execution of the transaction commands. It assumes familiarity with the Sui object model and the Move language. For more information on those topics, see the following documents: Object model Move Concepts Transaction type There are two parts of a PTB that are relevant to execution semantics. Other transaction information, such as the transaction sender or the gas limit, might be referenced but are out of scope. The structure of a PTB is: { inputs: [Input], commands: [Command], } Looking closer at the two main components: The inputs value is a vector of arguments, [Input]. These arguments are either objects or pure values that you can use in the commands. The objects are either owned by the sender or are shared/immutable objects. The pure values represent simple Move values, such as u64 or String values, which you can be construct purely from their bytes. For historical reasons, Input is CallArg in the Rust implementation. The commands value is a vector of commands, [Command]. The possible commands are: TransferObjects sends multiple (one or more) objects to a specified address. SplitCoins splits off multiple (one or more) coins from a single coin. It can be any sui::coin::Coin object. MergeCoins merges multiple (one or more) coins into a single coin. Any sui::coin::Coin objects can be merged, as long as they are all of the same type. MakeMoveVec creates a vector (potentially empty) of Move values. This is used primarily to construct vectors of Move values to be used as arguments to MoveCall. MoveCall invokes either an entry or a public Move function in a published package. Publish creates a new package and calls the init function of each module in the package. Upgrade upgrades an existing package. The upgrade is gated by the sui::package::UpgradeCap for that package. Inputs and results Inputs and results are the two types of values you can use in transaction commands. Inputs are the values that are provided to the PTB, and results are the values that are produced by the PTB commands. The inputs are either objects or simple Move values, and the results are arbitrary Move values (including objects). The inputs and results can be seen as populating an array of values. For inputs, there is a single array, but for results, there is an array for each individual transaction command, creating a 2D-array of result values. You can access these values by borrowing (mutably or immutably), by copying (if the type permits), or by moving (which takes the value out of the array without re-indexing). Inputs Input arguments to a PTB are broadly categorized as either objects or pure values. The direct implementation of these arguments is often obscured by transaction builders or SDKs. This section describes information or data the Sui network needs when specifying the list of inputs, [Input]. Each Input is either an object, Input::Object(ObjectArg), which contains the necessary metadata to specify to object being used, or a pure value, Input::Pure(PureArg), which contains the bytes of the value. For object inputs, the metadata needed differs depending on the type of ownership of the object. The data for the ObjectArg enum follows: If the object is owned by an address (or it is immutable), then use ObjectArg::ImmOrOwnedObject(ObjectID, SequenceNumber, ObjectDigest). The triple respectively specifies the object's ID, its sequence number (also known as its version), and the digest of the object's data. If an object is shared, then use Object::SharedObject { id: ObjectID, initial_shared_version: SequenceNumber, mutable: bool }. Unlike ImmOrOwnedObject, a shared objects version and digest are determined by the network's consensus protocol. The initial_shared_version is the version of the object when it was first shared, which is used by consensus when it has not yet seen a transaction with that object. While all shared objects can be mutated, the mutable flag indicates whether the object is to be used mutably in this transaction. In the case where the mutable flag is set to false, the object is read-only, and the system can schedule other read-only transactions in parallel. If the object is owned by another object, as in it was sent to an object's ID via the TransferObjects command or the sui::transfer::transfer function, then use ObjectArg::Receiving(ObjectID, SequenceNumber, ObjectDigest). The object data is the same as for the ImmOrOwnedObject case. For pure inputs, the only data provided is the BCS bytes, which are deserialized to construct Move values. Not all Move values can be constructed from BCS bytes. This means that even if the bytes match the expected layout for a given Move type, they cannot be deserialized into a value of that type unless the type is one of the types permitted for Pure values. The following types are allowed to be used with pure values: All primitive types: u8 u16 u32 u64 u128 u256 bool address A string, either an ASCII string (std::ascii::String) or UTF8 string (std::string::String). In either case, the bytes are validated to be a valid string with the respective encoding. An object ID sui::object::ID. A vector, vector, where T is a valid type for a pure input, checked recursively. An option, std::option::Option, where T is a valid type for a pure input, checked recursively. Interestingly, the bytes are not validated until the type is specified in a command, for example in MoveCall or MakeMoveVec. This means that a given pure input could be used to instantiate Move values of several types. See the Arguments section for more details. Results Each transaction command produces a (possibly empty) array of values. The type of the value can be any arbitrary Move type, so unlike inputs, the values are not limited to objects or pure values. The number of results generated and their types are specific to each transaction command. The specifics for each command can be found in the section for that command, but in summary: MoveCall: the number of results and their types are determined by the Move function being called. Move functions that return references are not supported at this time. SplitCoins: produces (one or more) coins from a single coin. The type of each coin is sui::coin::Coin where the specific coin type T matches the coin being split. Publish: returns the upgrade capability, sui::package::UpgradeCap, for the newly published package. Upgrade: returns the upgrade receipt, sui::package::UpgradeReceipt, for the upgraded package. TransferObjects and MergeCoins do not produce any results (an empty result vector). Argument structure and usage Each command takes Arguments that specify the input or result being used. The usage (by-reference or by-value) is inferred based on the type of the argument and the expected argument of the command. First, examine the structure of the Argument enum. Input(u16) is an input argument, where the u16 is the index of the input in the input vector. For example, given an input vector of [Object1, Object2, Pure1, Object3], Object1 is accessed with Input(0) and Pure1 is accessed with Input(2). GasCoin is a special input argument representing the object for the SUI coin used to pay for gas. It is kept separate from the other inputs because the gas coin is always present in each transaction and has special restrictions (see below) not present for other inputs. Additionally, the gas coin being separate makes its usage explicit, which is helpful for sponsored transactions where the sponsor might not want the sender to use the gas coin for anything other than gas. The gas coin cannot be taken by-value except with the TransferObjects command. If you need an owned version of the gas coin, you can first use SplitCoins to split off a single coin. This limitation exists to make it easy for the remaining gas to be returned to the coin at the end of execution. In other words, if the gas coin was wrapped or deleted, then there would not be an obvious spot for the excess gas to be returned. See the Execution section for more details. NestedResult(u16, u16) uses the value from a previous command. The first u16 is the index of the command in the command vector, and the second u16 is the index of the result in the result vector of that command. For example, given a command vector of [MoveCall1, MoveCall2, TransferObjects] where MoveCall2 has a result vector of [Value1, Value2], Value1 would be accessed with NestedResult(1, 0) and Value2 would be accessed with NestedResult(1, 1). Result(u16) is a special form of NestedResult where Result(i) is roughly equivalent to NestedResult(i, 0). Unlike NestedResult(i, 0), Result(i), however, this errors if the result array at index i is empty or has more than one value. The ultimate intention of Result is to allow accessing the entire result array, but that is not yet supported. So in its current state, NestedResult can be used instead of Result in all circumstances. Execution {#execution} For the execution of PTBs, the input vector is populated by the input objects or pure value bytes. The transaction commands are then executed in order, and the results are stored in the result vector. Finally, the effects of the transaction are applied atomically. The following sections describe each aspect of execution in greater detail. Start of execution At the beginning of execution, the PTB runtime takes the already loaded input objects and loads them into the input array. The objects are already verified by the network, checking rules like existence and valid ownership. The pure value bytes are also loaded into the array but not validated until usage. The most important thing to note at this stage is the effects on the gas coin. At the beginning of execution, the maximum gas budget (in terms of SUI) is withdrawn from the gas coin. Any unused gas is returned to the gas coin at the end of execution, even if the coin has changed owners. Executing a transaction command Each transaction command is then executed in order. First, examine the rules around arguments, which are shared by all commands. Arguments {#arguments} You can use each argument by-reference or by-value. The usage is based on the type of the argument and the type signature of the command. If the signature expects an &mut T, the runtime checks the argument has type T and it is then mutably borrowed. If the signature expects an &T, the runtime checks the argument has type T and it is then immutably borrowed. If the signature expects a T, the runtime checks the argument has type T and it is copied if T: copy and moved otherwise. No object in Sui has copy because the unique ID field sui::object::UID present in all objects does not have the copy ability. The transaction fails if an argument is used in any form after being moved. There is no way to restore an argument to its position (its input or result index) after it is moved. If an argument is copied but does not have the drop ability, then the last usage is inferred to be a move. As a result, if an argument has copy and does not have drop, the last usage must be by value. Otherwise, the transaction will fail because a value without drop has not been used. The borrowing of arguments has other rules to ensure unique safe usage of an argument by reference. If an argument is: Mutably borrowed, there must be no outstanding borrows. Duplicate borrows with an outstanding mutable borrow could lead to dangling references (references that point to invalid memory). Immutably borrowed, there must be no outstanding mutable borrows. Duplicate immutable borrows are allowed. Moved, there must be no outstanding borrows. Moving a borrowed value would dangle those outstanding borrows, making them unsafe. Copied, there can be outstanding borrows, mutable or immutable. While it might lead to some unexpected results in some cases, there is no safety concern. Object inputs have the type of their object T as you might expect. However, for ObjectArg::Receiving inputs, the object type T is instead wrapped as sui::transfer::Receiving. This is because the object is not owned by the sender, but instead by another object. And to prove ownership with that parent object, you call the sui::transfer::receive function to remove the wrapper. The GasCoin has special restrictions on being used by-value (moved). You can only use it by-value with the TransferObjects command. Shared objects also have restrictions on being used by-value. These restrictions exist to ensure that at the end of the transaction the shared object is either still shared or deleted. A shared object cannot be unshared (having the owner changed) and it cannot be wrapped. A shared object: Marked as not mutable (being used read-only) cannot be used by value. Cannot be transferred or frozen. These checks are not done dynamically, however, but rather at the end of the transaction only. For example, TransferObjects succeeds if passed a shared object, but at the end of execution the transaction fails. Can be wrapped and can become a dynamic field transiently, but by the end of the transaction it must be re-shared or deleted. Pure values are not type checked until their usage. When checking if a pure value has type T, it is checked whether T is a valid type for a pure value (see the previous list). If it is, the bytes are then validated. You can use a pure value with multiple types as long as the bytes are valid for each type. For example, you can use a string as an ASCII string std::ascii::String and as a UTF8 string std::string::String. However, after you mutably borrow the pure value, the type becomes fixed, and all future usages must be with that type. TransferObjects The command has the form TransferObjects(ObjectArgs, AddressArg) where ObjectArgs is a vector of objects and AddressArg is the address the objects are sent to. Each argument ObjectArgs: [Argument] must be an object, however, the objects do not need to have the same type. The address argument AddressArg: Argument must be an address, which could come from a Pure input or a result. All arguments, objects and address, are taken by value. The command does not produce any results (an empty result vector). While the signature of this command cannot be expressed in Move, you can think of it roughly as having the signature (vector, address): () where forall T: key + store. T is indicating that the vector is a heterogeneous vector of objects. SplitCoins The command has the form SplitCoins(CoinArg, AmountArgs) where CoinArg is the coin being split and AmountArgs is a vector of amounts to split off. When the transaction is signed, the network verifies that the AmountArgs is non-empty. The coin argument CoinArg: Argument must be a coin of type sui::coin::Coin where T is the type of the coin being split. It can be any coin type and is not limited to SUI coins. The amount arguments AmountArgs: [Argument] must be u64 values, which could come from a Pure input or a result. The coin argument CoinArg is taken by mutable reference. The amount arguments AmountArgs are taken by value (copied). The result of the command is a vector of coins, sui::coin::Coin. The coin type T is the same as the coin being split, and the number of results matches the number of arguments For a rough signature expressed in Move, it is similar to a function (coin: &mut sui::coin::Coin, amounts: vector): vector> where the result vector is guaranteed to have the same length as the amounts vector. MergeCoins The command has the form MergeCoins(CoinArg, ToMergeArgs) where the CoinArg is the target coin in which the ToMergeArgs coins are merged into. In other words, you merge multiple coins (ToMergeArgs) into a single coin (CoinArg). When the transaction is signed, the network verifies that the AmountArgs is non-empty. The coin argument CoinArg: Argument must be a coin of type sui::coin::Coin where T is the type of the coin being merged. It can be any coin type and is not limited to SUI coins. The coin arguments ToMergeArgs: [Argument] must be sui::coin::Coin values where the T is the same type as the CoinArg. The coin argument CoinArg is taken by mutable reference. The merge arguments ToMergeArgs are taken by value (moved). The command does not produce any results (an empty result vector). For a rough signature expressed in Move, it is similar to a function (coin: &mut sui::coin::Coin, to_merge: vector>): () MakeMoveVec The command has the form MakeMoveVec(VecTypeOption, Args) where VecTypeOption is an optional argument specifying the type of the elements in the vector being constructed and Args is a vector of arguments to be used as elements in the vector. When the transaction is signed, the network verifies that if that the type must be specified for an empty vector of Args. The type VecTypeOption: Option is an optional argument specifying the type of the elements in the vector being constructed. The TypeTag is a Move type for the elements in the vector, i.e. the T in the produced vector. The type does not have to be specified for an object vector--when T: key. The type must be specified if the type is not an object type or when the vector is empty. The arguments Args: [Argument] are the elements of the vector. The arguments can be any type, including objects, pure values, or results from previous commands. The arguments Args are taken by value. Copied if T: copy and moved otherwise. The command produces a single result of type vector. The elements of the vector cannot then be accessed individually using NestedResult. Instead, the entire vector must be used as an argument to another command. If you wish to access the elements individually, you can use the MoveCall command and do so inside of Move code. While the signature of this command cannot be expressed in Move, you can think of it roughly as having the signature (T...): vector where T... indicates a variadic number of arguments of type T. MoveCall This command has the form MoveCall(Package, Module, Function, TypeArgs, Args) where Package::Module::Function combine to specify the Move function being called, TypeArgs is a vector of type arguments to that function, and Args is a vector of arguments for the Move function. The package Package: ObjectID is the Object ID of the package containing the module being called. The module Module: String is the name of the module containing the function being called. The function Function: String is the name of the function being called. The type arguments TypeArgs: [TypeTag] are the type arguments to the function being called. They must satisfy the constraints of the type parameters for the function. The arguments Args: [Argument] are the arguments to the function being called. The arguments must be valid for the parameters as specified in the function's signature. Unlike the other commands, the usage of the arguments and the number of results are dynamic in that they both depend on the signature of the Move function being called. Publish {#publish} The command has the form Publish(ModuleBytes, TransitiveDependencies) where ModuleBytes are the bytes of the module being published and TransitiveDependencies is a vector of package Object ID dependencies to link against. When the transaction is signed, the network verifies that the ModuleBytes are not empty. The module bytes ModuleBytes: [[u8]] contain the bytes of the modules being published with each [u8] element is a module. The transitive dependencies TransitiveDependencies: [ObjectID] are the Object IDs of the packages that the new package depends on. While each module indicates the packages used as dependencies, the transitive object IDs must be provided to select the version of those packages. In other words, these object IDs are used to select the version of the packages marked as dependencies in the modules. After the modules in the package are verified, the init function of each module is called in same order as the module byte vector ModuleBytes. The command produces a single result of type sui::package::UpgradeCap, which is the upgrade capability for the newly published package. Upgrade The command has the form Upgrade(ModuleBytes, TransitiveDependencies, Package, UpgradeTicket), where the Package indicates the object ID of the package being upgraded. The ModuleBytes and TransitiveDependencies work similarly as the Publish command. For details on the ModuleBytes and TransitiveDependencies, see the Publish command. Note though, that no init functions are called for the upgraded modules. The Package: ObjectID is the Object ID of the package being upgraded. The package must exist and be the latest version. The UpgradeTicket: sui::package::UpgradeTicket is the upgrade ticket for the package being upgraded and is generated from the sui::package::UpgradeCap. The ticket is taken by value (moved). The command produces a single result type sui::package::UpgradeReceipt which provides proof for that upgrade. For more details on upgrades, see Upgrading Packages. End of execution At the end of execution, the remaining values are checked and effects for the transaction are calculated. For inputs, the following checks are performed: Any remaining immutable or readonly input objects are skipped since no modifications have been made to them. Any remaining mutable input objects are returned to their original owners--if they were shared they remain shared, if they were owned they remain owned. Any remaining pure input values are dropped. Note that pure input values must have copy and drop since all permissible types for those values have copy and drop. For any shared object you must also check that it has only been deleted or re-shared. Any other operation (wrap, transfer, freezing, and so on) results in an error. For results, the following checks are performed: Any remaining result with the drop ability is dropped. If the value has copy but not drop, it's last usage must have been by-value. In that way, it's last usage is treated as a move. Otherwise, an error is given because there is an unused value without drop. Any remaining SUI deducted from the gas coin at the beginning of execution is returned to the coin, even if the owner has changed. In other words, the maximum possible gas is deducted at the beginning of execution, and then the unused gas is returned at the end of execution (all in SUI). Because you can take the gas coin only by-value with TransferObjects, it will not have been wrapped or deleted. The total effects (which contain the created, mutated, and deleted objects) are then passed out of the execution layer and are applied by the Sui network. Example Let's walk through an example of a PTB's execution. While this example is not exhaustive in demonstrating all the rules, it does show the general flow of execution. Suppose you want to buy two items from a marketplace costing 100 MIST. You keep one for yourself, and then send the object and the remaining coin to a friend at address 0x808. You can do that all in one PTB: { inputs: [ Pure(/* @0x808 BCS bytes */ ...), Object(SharedObject { /* Marketplace shared object */ id: market_id, ... }), Pure(/* 100u64 BCS bytes */ ...), ] commands: [ SplitCoins(GasCoin, [Input(2)]), MoveCall("some_package", "some_marketplace", "buy_two", [], [Input(1), NestedResult(0, 0)]), TransferObjects([GasCoin, NestedResult(1, 0)], Input(0)), MoveCall("sui", "tx_context", "sender", [], []), TransferObjects([NestedResult(1, 1)], NestedResult(3, 0)), ] } The inputs include the friend's address, the marketplace object, and the value for the coin split. For the commands, split off the coin, call the market place function, send the gas coin and one object, grab your address (via sui::tx_context::sender), and then send the remaining object to yourself. For simplicity, the documentation refers to the package names by name, but note that in practice they are referenced by the package's Object ID. To walk through this, first look at the memory locations, for the gas object, inputs, and results Gas Coin: sui::coin::Coin { id: gas_coin, balance: sui::balance::Balance { value: 1_000_000u64 } } Inputs: [ Pure(/* @0x808 BCS bytes */ ...), some_package::some_marketplace::Marketplace { id: market_id, ... }, Pure(/* 100u64 BCS bytes */ ...), ] Results: [] Here you have two objects loaded so far, the gas coin with a value of 1_000_000u64 and the marketplace object of type some_package::some_marketplace::Marketplace (these names and representations are shortened for simplicity going forward). The pure arguments are not loaded, and are present as BCS bytes. Note that while gas is deducted at each command, that aspect of execution is not demonstrated in detail. Before commands: start of execution Before execution, remove the gas budget from the gas coin. Assume a gas budget of 500_000 so the gas coin now has a value of 500_000u64. Gas Coin: Coin { id: gas_coin, ... value: 500_000u64 ... } // The maximum gas is deducted Inputs: [ Pure(/* @0x808 BCS bytes */ ...), Marketplace { id: market_id, ... }, Pure(/* 100u64 BCS bytes */ ...), ] Results: [] Now you can execute the commands. Command 0: SplitCoins The first command SplitCoins(GasCoin, [Input(2)]) accesses the gas coin by mutable reference and loads the pure argument at Input(2) as a u64 value of 100u64. Because u64 has the copy ability, you do not move the Pure input at Input(2). Instead, the bytes are copied out. For the result, a new coin object is made. This gives us updated memory locations of Gas Coin: Coin { id: gas_coin, ... value: 499_900u64 ... } Inputs: [ Pure(/* @0x808 BCS bytes */ ...), Marketplace { id: market_id, ... }, Pure(/* 100u64 BCS bytes */ ...), ] Results: [ [Coin { id: new_coin, value: 100u64 ... }], // The result of SplitCoins ],
4How to Perform Cross-Contract Calls?
I am seeking references or guidance on how to execute cross-contract calls within a smart contract. If anyone could provide insights or resources on this topic, it would be greatly appreciated. Additionally, if possible, could someone share an example demonstrating the implementation of cross-contract calls for better understanding? Thank you in advance for your assistance.
43- ForCartesiNov 14, 2023
What is blockchain technology?
What is blockchain technology?What is blockchain technology?
32