A smart contract can be compiled into EVM bytecode (Ethereum Virtual Machine) and deployed to Ethereum blockchain on a block with specific block height, and return a transaction hash.
But in what way does a smart contract stored on a block? And how does the blockchain record state change, when a transaction has been issued to interact with that smart contract to change its state (e.g. the value of a variable)?
You need to distinguish two things stored in blokchain (both of them are stateless and immutable):
smart contract templates
transactions/events
Final smart contract state isn't stored in blocks directly. It is computed by node (ethereum virtual machine) from previously mentioned templates and transactions.
Related
I want to make some calculations and store their result in an account after user sends some money to my PDA. How can I do it? My understanding is that I cannot transfer funds from user inside a smart contract, and I can only transfer from my PDA to user, not vice verse, am I correct? Is it a proper solution, if I store my lamports amount in an account, and then inside my instrucition compare the previous value to the actual value, and from front end I run transfer of SOL and my instruction as 2 instructions of a single transaction?
First: You can send SOL/lamports within your program from a PDA, shown here, or program owned account to any account.
Secondly: You can use CPI within your program to transfer SOL/lamports from a system owned account to your program but you will need the source signer to do so.
So, if your instruction took the signer's account you could transfer SOL from their account to your PDA in one instruction (although you are invoking the transfer within your instruction to get the source SOL).
Is there a tool that can estimate how much gas a contract call will make before submitting to the NEAR network?
Currently the best estimation is to use runtime-standalone, which can process transactions without having to worry about consensus/networking. This means you can create accounts, deploy contracts, and invoke them and the outcome returned includes how much gas was burnt and used. The difference being burnt gas is used to execute the function call and used gas is how much was used by contract promise calls.
However, it's currently a MVP prototype and has only been used to test our core contract, here is it being used to test the lockup contract.
If your contract method doesn't invoke any batch promises and only normal promises,the mock runtime in near-sdk-as provides a way to create accounts and "deploy" contracts. It does this by internally using the binary of near-vm-runner-standalone, which is a rust crate. The binary provides a CLI to invoke a single transaction, which takes as input the current state of the contract being called, the contract's binary, the config file that defines the current context (who is calling the contract, how much gas is prepaid, etc), and a config for the cost of different fees. It then returns the updated state, the outcome of the transaction (e.g. how much gas was used and any receipts of transactions queued by promise calls).
The near-vm-runner-standalone is also published to npm with the package name: near-vm, which is what the mock runtime uses.
This is still an active area of development and we hope to turn runtime standalone into a useful easy to use tool for testing and gas estimation.
The easiest way to do it is to submit sample transaction with more than needed gas attached and then check in explorer how much gas was used, e.g. see
https://explorer.testnet.near.org/transactions/23dgV15pydiVhirWJ4He7TMoyRJM2DUXtcWb7VXFSy2G
300 Tgas was attached and 47 Tgas used for that given transaction.
I have a few questions regarding the cordite dgl tokens.
I want to tokenize an asset which is represented as LinearState.
Is there a way to only allow a single issuance of tokens?
Is the preferred way to link the tokens to other states through the TokenSymbol?
What is the intended design of accounts? One Account per usecase or one per TokenType?
How do I query if a specific token already exists? Is the only way to query for an account and look at the result (so there is no function to search for balance by TokenSymbol)?
Thanks in advance!
Great questions, thanks!
It's not possible right now but it's definitely recognised as being desirable. It will require a change to the core which is fine. I think this work will require Corda 4, notably reference states and linear state pointer types for it to work. Notably, we will want:
a. There are so many ways of limiting issuance: not only by final amount, but also by distribution rate, signing parties (in the case where multiple are required for the issuance) etc. We need means of inserting the notion of finite issuance into the token type, optionally. This will be either adding additional fields to the existing TokenType. Or better, making TokenType open so that it can be extended. Another way is to provide a field to a base type or interface that will encode the contract rules.
b. we could transfer the token type as an attached StateAndRef, but we need to be conscious of the per tx storage, network, signing and verification cost of doing this. A better approach is to use the reference data feature in Corda 4 that we are eagerly waiting for.
If the other states are part of the same transaction that emits the tokens, then the linking is implicit. If the other state is not in the same transaction as the token, then linking for now, in Corda 3, would need to use TokenType descriptor. Alternatively, it can also reference a StateAndRef in the tx that generates the other state. The most efficient we think is to use Corda 4's reference states (scheduled for Dec/Jan this year I believe)
Accounts are designed to store tokens of multiple token types. They are really aligned for the business use-case and aren't limited by specific token types, unless you want to enfore that in the application layer.
Do you mean you want to get the balance of a TokenType across all accounts? You can certainly use the Corda's API to locate Tokens - this isn't exposed via Braid yet but could certainly could be. Another approach is to tag/alias all your accounts with the same tag e.g. { category:'all-accounts', value:''} You can then do a ledger.balanceForAccountTag({ category: 'all-accounts', value:''}) to get balances across all accounts. However, this returns the balances for all TokenTypes. What would the ideal API look like for you?
I am working on a windows system. I need to create a shared memory for inter process communication to share objects (containing pointers as members). Or some equivalent way for fast transfer of objects from a generator process to a receiver process. the size of the objects are also huge. How do i do that? The porblem is that even if i share the objects I need a way so that the other process gets the access to the locations pointed by the pointers in the objects. And sharing each of those locations for each object is not feasible.
It's difficult to say without more details, but I would consider a memory mapped file. How you create the file depends on whether you need to communicate between sessions or not. You would also need a notification mechanism when new data was posted. You could do that with a registered message, but again that's only possible if your processes are in the same session/desktop.
I can't really be more specific without knowing the details of the requirement.
So. Before I get singleton pattern hate on this message hear me out. I'd love to hear ideas. I'm making a program that I think I need to use core data for, because later I want the status of some variables to be easily accessible from OS X, and multiple iOS devices.
What I'm making is an OS X program that will control phidgets (phidgets.com) to control and listen for status changes in real world objects. Example: whether a motor is turned on or not. Turn a motor on and off. Turn on status lights, etc.
I originally thought I'd just make global variables that I change, poll and manipulate in order to have a central status board for the logic of the program to work off of. But, because of the engineering that is put into core data every year by apple, I am assuming making this work with core data will allow me to more easily have options to sync this later with iOS devices that could control or monitor the said status' remotely.
Is there a nifty way you can imagine to:
-startup the program, confirm there is only one entity of type "SystemStatus", if there isn't one, make one. is there is one, we continue and are able to let the program update it's attributes with status of the real world objects it's controlling.
using core data was something I thought of also, because it will allow me a place to persist stored history of data gathered too. Example: motor bearing temperature over time.
If you ensure that access to this object is done through your API, Core Data becomes an implementation detail behind the getter method of the singleton object. There are no facilities in Core Data to tell it to create only one object, but if you ensure access to the object is done through a wrapper of your own, you can fetch it on demand and if it doesn't exist, you can insert it, save, and pass it to the caller.
An important thing to consider when using Core Data objects is multithreading. Passing the same object to multiple threads is very error-prone and requires locking mechanisms (or use of Apple's block-based API). This is not very straightforward for what you describe. Consider either a wrapper object which uses Core Data objects internally (wraps access to properties in block-based API) or using a different approach than Core Data.