I'm interested in the conceptual topic of creating rights managements systems on the the Ethereum block chain with digital assets represented by an NFT.
I am just reading up on how to write programs that run on Etherium but I have some very basic questions just to get to started.
I read that NFT are created on the Ethereum blockchain. I don't really understand if that is the same block chain on which the currency Ether is maintained? Seems like the ledger will become impossibly large huge if both the every currency transaction and every digital asset and copy thereof that migrates to Ethereum is stored in one single giant ledger and that each miner on the chain has to download the entire ledger to one single machine in order to validate transactions? Have I got big misunderstanding there? I know there is talk about "sharding" in the future, but it seems like that isn't coming very soon.
Cost of running a smart contract on the blockchain? Assuming that the we are talking about the same block chain, from what I can see the price of "Gas" is quite high. I'm reading that the price of ETH transfer from one party to another is 21,000 Gwei, about $0.03 today. Just trying to understand the basics, how much does it cost to create a NFT? And roughly how much does it cosst to execute a simple function on the blockchain (without loops). Let say the equivalent of 5 statement function which takes a few simple params, reads a few blocks, doesn't write to the block chain but just performs some simple math and a few if statements and returns a string? Does that also cost, like, more than penny? Is the conversion to ETH2 switch from proof of work to proof of stake going to bring those costs down by orders of magnitude?
Any good resources or reference on how to write programs which create and manipulate NFTS on Etherium? Most of what I have seen in the bookstores seem to cover financial transactions with Ether.
Yes, it's the same blockchain.
You can see in the stats that full node (stores current state) currently takes about 400 GB and archive node (stores current and historical states as well) takes about 6.6 TB.
My observation is that most web apps using blockchain data don't verify and trust a third-party service running a node (such as Infura). And I believe that most end users or businesses who want/need to verify, usually have the capacity to store 400+ GB and are able to scale.
But if this amount of data is okay or "impossibly large huge", I'll leave that to your decision. :)
Deployment of a token smart contract usually costs between 500k to 3M gas. My estimate is that most token contracts with basic features that were compiled with an optimizer, cost around 1M gas to deploy. With current prices of ~200 Gwei/gas and $1800/ETH, that's about $350. But I remember just few months ago the average gas prices were ~20 and ETH cost $500, so that would be around $10. So yea, the cost of deploying a contract is very volatile.
Simple function that performs validations and transformations in memory is going to cost the base 21k + few hundred gas. (Working with memory data is cheap gas-wise, accessing the storage is much more expensive.) So in current prices around $7, few months ago it could have been $0.25.
As for the question, whether ETH2.0 is going to bring lower gas price: My opinion is that L2 (which should be released earlier than PoS) is going to have some effect on the price since it allows for sidechain transactions (similar to Lightning network on Bitcoin). But this is a development forum, so I'm not not going to dive deeper into price speculations.
I recommend OpenZeppelin docs where they cover their opensource implementations of ERC standards (including ERC-721 NFTs) or googling the topic you're interested in and read articles that catch your eye (at least that's my current approach).
And if you're new to Solidity in general, I recommend at least few chapters from CryptoZombies tutorial. In my opinion, the first few chapters are great and you'll learn a lot, but then the quality slowly fades.
Related
Gas costs for even a simple contract deployment are astronomical. If I spin up my own node and connect directly to it can I deploy on that node and avoid the gas fees?
Can I avoid gas fees by running my own Ethereum node?
Simple answer: No.
A node accepts the transaction, stores it in its mempool, and relays it to other nodes so that they can also store it in their mempool. There's nothing related to gas costs at this point.
Theoretically you could deploy a contract for "free" by running your own miner. But that's impossible without professional hardware costing very large amounts - many times more expensive than what you'd save on the gas fees.
However, in a block that you mined, you could include a transaction deploying a contract with 0 gas price. This sometimes happens - miners do occasionally put their own 0-priced transactions in their own blocks. But apart from that, no miner would accept your transaction with 0 gas price (or any transaction priced lower than the current market rate), as that wouldn't be profitable for them.
I see that Google Cloud may terminate preemptible instances at any time, but have any unofficial, independent studies been reported, showing "preempt rates" (number of VMs preempted per hour), perhaps sampled in several different regions?
Given how little information I'm finding (as with similar questions), even anecdotes such as: "Looking back the past 6 months, I generally see 3% - 5% instances preempt per hour in uswest1" would be useful (I presume this can be monitored similarly to instance count metrics in AWS).
Clients occasionally want to shove their existing, non-fault-tolerant code in the cloud for "cheap" (despite best practices), and without having an expected rate of failure, they're often blind-sighted by the cheapness of preemptible, so I'd like to share some typical experiences of the GCP community, even if people's experiences may vary, to help convey safe expectations.
Thinking about “unofficial, independent studies” and “even anecdotes such as:” “Clients occasionally want to shove their existing, non-fault-tolerant code in the cloud for "cheap"” it ought to be said that no one architect or sysadmin in right mind would place production workloads with defined SLA into an execution environment without SLA. Hence the topic is rather speculative.
For those who is keen, Google provides preemption rate expectation:
For reference, we've observed from historical data that the average
preemption rate varies between 5% and 15% per day per project, on a
seven-day average, occasionally spiking higher depending on time and
zone. Keep in mind that this is an observation only: Preemptible
instances have no guarantees or SLAs for preemption rates or
preemption distributions.
Besides that there is an interesting edutainment approach to the task of "how to make inapplicable applicable".
I have a simulation that ticks the time every 5 seconds. I want to use OpenAI and its baselines algorithms to perform learning in this environment. For that I'd like to adapt the simulation by writing some adapter code that corresponds to the OpenAI Env API. But there is a problem: The flow of control is defined by the Agent in the OpenAI setting. But in my world, the environment steps, independent of the agent. If the agent doesn't decide or is not fast enough, the world just keeps going without him. How would one achieve this reversal of triggering the next step?
In short: OpenAI Env gets stepped by the agent. My environment gives my agent about 2-3 seconds to decide and then just tells it what's new, again offering to make choice to act or not.
As an example: My environment is rather similar to a real world stock trading market. The agent gets 24 chances to buy / sell products for a certain limit price to accumulate a certain volume for that target time and at time step 24, the reward is given to the agent and the slot is completed. The reward is based on the average price paid per item in comparison to the average price by all market participants.
At any given moment, 24 slots are traded in parallel (a 24x parallel trading of futures). I believe for this I need to create 24 environments which leads me to believe A3C would be a good choice.
After re-reading the question, it seems like OpenAI gym is not a great fit for what you’re trying to do. It is designed for running rapid experiments, which cannot be done efficiently if you are waiting on live events to occur. If you have no historical data and can only train on incoming live data, there is no point to using OpenAI gym. You can write your own code to represent the environment from that data, and that would be easier than trying to morph it into another framework, although OpenAI gym’s API does provide a good model for how your environment should work.
I was wondering how ethereum blockchain works compared with the bitcoin blockchain.
I know that, in bitcoin, all nodes compete to mine blocks (and put to public transaction into them and thus make bitcoin as transaction processing fee), and that all nodes compete for the next block at one time with an equal chance of mining it.
But in ethereum, where you want a network of distributed apps that get executed according to the gas price they are willing to pay (and starting gas), are all nodes competing for the next block at one given time? Wouldn't this be a waste of computation?
Yes, all the nodes do compete for (pretty much) the same blocks, and yes - they do execute all the code in a block, even if this block is not going to be successfully mined.
Don't think of it as "waste," but rather as a mechanism to ensure proof of work.
In short, yes, there is a lot of wasted computation.
Ethereum's mining process is almost the same as bitcoin’s.
For each block of transactions, miners will run the block’s unique header metadata (including timestamp and software version) through a hash function. If the miner finds a hash that matches the current target, the miner will be awarded ether and broadcast the block across the network for each node to validate and add to their own copy of the ledger. If miner B finds the hash, miner A will stop work on the current block and repeat the process for the next block.
I have recently downloaded the GUI wallet, and it gives the option to create contract based wallets and connect to them to a main account. What is the difference between using a contract based wallet and an account? And what should be used to store my ether?
Contract-based wallets are more robust and can be more secure. For example, a contract can be setup to require transfers over a certain threshold to be approved my multiple people/keys. Even if these keys all reside on your local computer, having to compromise even a slightly-improved 2 of 3 can provide far greater security than a single key alone.
Additionally, contracts benefit from transaction receipts, which contain a permanent log of all events. This makes it much easier to inspect the state and verify the history of a contract. For example, when a new transaction request is initiated against a wallet contract requiring multiple signatures, an event log for "ConfirmationNeeded" with the operation ID will be added. After the operation has received the appropriate number of signatures, a "MultiTransact" might occur containing the recipient, value, and associated data with the transaction.
Standard accounts benefit from none of this and can only send transactions, not respond autonomously.
Here are advantages and disadvantages for comparison.
Advantages of contract-based account wallets:
Funds are not stored on a single key.
You can cycle through management keys.
Mutisig functionality; only execute a transaction on majority rule (eg. Gnosis Multisig)
Allows for account recovery, in case your management keys are lost (eg. Argent).
Set transfer and withdraw limits enforced by the contract.
You can have access controls for keys, meaning you can restrict what methods a key can invoke. Useful when you want to delegate control to someone else but restrict what they can do.
Batched transactions; execute multiple transactions as 1 atomic transaction.
Defi protocol composition; easily integrate with other smart contracts (eg. one-click DAI saving rate accounts)
Meta transactions: pay your transaction costs using a different asset, like a token (eg. Gas Station Network). Relayers may also offer free transactions (eg. Authereum)
Disadvantages of contract-based account wallets:
Contract are susceptible to attacks; people write buggy code all the time (eg. Parity hack). An Externally-owned account (EOA) can't be hacked because there is no code to hack.
Backward incompatible features may render funds locked if contract not properly written. (eg. Istanbul hardfork gas cost changes)
Deployment costs; unlikes key pairs which doesn't cost anything to generate, there's a fee cost for deploying contract-based accounts.