I have a newbie question. As I understand, ethereum internal transactions are not stored on-chain. One can replay them when replaying the blocks. This seems to assume that smart contracts' behavior is deterministic. What if there are oracles? Does that make the smart contract's behavior nondeterministic and therefore one can't always replay the same internal transactions?
A blockchain oracle is any device or entity that connects a deterministic blockchain with off-chain data. The way they work is these oracles actually enter data on the blockchain through an external transaction. this way we can guarantee that the blockchain has all the information needs to verify itself. So instead of calling an API, an off-chain oracle will actually get the API and then report it on chain in a transaction. that way there is no API calling in the ethereum. Oracles are known as blockchain middlewares as they bridge the blockchain world to the real world.
Oracles are trusted entities because they are capable of digitally signing or digitally attesting the data to prove that the data is authentic. This proof is called proof of validity or proof of authenticity.
Oracles should not be able to manipulate the data they provide and must be able to provide factual data. Even though oracles
are trusted, it may still be possible that,
in some cases, the data is incorrect due to manipulation or a fault in the system. Therefore, oracles must not be able to modify the data. This validation can be provided by using various cryptographic proofing schemes. Some mechanisms to produce proof of data security:
TLSNotary
Android proof
Ledger proof
Trusted hardware-assisted proofs
DEcentralized Oracles:
As blockchain platforms such are fully decentralized, it is expected that oracle services should also be decentralized. This type of oracle can be built based on a distributed mechanism. For more You can read here:
https://medium.com/stakin/the-top-decentralized-oracles-169b94dfbb83
Related
I am planning out a new project in which I need to connect one particular Fiat payment gateway to my smart contract. I don't want to have a system with a centralized backend, so I am exploring the possibility to use Chainlink to communicate with API and then pass response to my smart contract. I know that Chainlink allows any contract to access any external data source through their decentralized oracle network. The problem is I can't approximate how much LINK it will cost me to get a response from 1 oracle. Is there some average cost of a 1 response from an oracle and what determines such cost
I tried to look up this information, but it does not seem that this topic is discussed much. Also probably I didn't look in the right place
The problem is I can't approximate how much LINK it will cost me to
get response from 1 oracle.
Nobody can. When you make a request to oracle, you are calling a smart contract function and this will cost you gas which varies depending on the congestion in the system. if system is busy, it will cost more gas. Also when you interact with the chainlink, you are actually passing data to chainlink smart contract which makes some calculations, so you pay for those gas too.
Calling one oracle is sending a request to one oracle. oracle is a chainlink node operator, and it set its own price. But sending a request to only one node is not a decentralized approach even though each node have multiple data resources. you should make a request to several nodes meaning that you need to pay each node operator. when you make a request to several nodes, you receive the average of those responses.
The service you want to use is Chainlink Any Api, and in the service the cost of LINK depends on the node operator you are using.
There is a fee required by node operator. When you send a request, you actually require Chainlink node to provide a service. Usually the service is not free and the fee of a request is set by the node operator. The fee varies across different node operators. If you are only a consumer to use service provided by node operators, you just need to check the fee of different node operators.
you, of course, also has to pay gas fee for your transaction, but that it it costed in ETH rather than LINK (as you asking how much LINK it will cost, I assume you know it).
If you are a node operator and want to run the service for yourself, you may want to consider the following 2 factors:
Congestion of the system mentioned by #Yilmaz. When the blockchain you are using is very busy, the gas price is high so that the more gas fee, which is the result of (gas price) x(gas limit), will be cost more.
The logic of fulfill function in your contract. Fulfillment function is the "callback" function of Chainlink Any Api. Oracle node will fetch the data demand in the request and then call the fulfill function in consumer contract. In fulfill function, logics varies from simply saving the data in a variable or doing some calculations. The more complex logics, the more gas limit required.
Hope it helps!
Is it correct that everyone can see my source code once smart contract code has been published to blockchain?
Is it correct that everyone can see application's businesss state and information saved in blockchain?
For example, the example below sends a request to blockchain, receives response from blockchain. In this case, can anyone see the source code and business information? The app uses Ethereum blockchain via Solidity.
https://learn.microsoft.com/en-us/azure/blockchain/service/send-transaction
Is it possible to protect source code and users can only see business states via UI? like conventional web applications.
Smart contract state and any information stored in the blockchain is visible to all observers outside of the blockchain, even local and private variables. (It is not necessarily visible to other smart contracts).
The solidity source code itself is not stored on the blockchain, only the compiled bytecode, which consist of low-level machine instructions (called opcodes) for the Ethereum Virtual Machine. Although this can't easily be converted back into your source code (i.e. all variable names will be missing), it does reveal information about what your code is doing.
In any blockchain the business info/state is visible to the participants of the blockchain network or consortium. Any smart contract state changes in done via a transaction that is shared between the participants of the transaction. Hence the contents/operations exposed via that smart contract is also visible to the participants of that transaction, so that they can verify it's validity / have a consensus on whether to accept/reject it.
To answer your question "everyone" may not be able to see the contents unless it is a public smart contract / transaction you are dealing with. in case of public transaction/contracts it is visible to that public chain. If it is a private transaction, then it is only visible to the participants of the private transaction.
Reference: Q&A
I want to know the exact effect of submitting a smart-contract call. For example, if I swap USDC to ETH on uniswap.
For transactions, we have eth_call, is there something similar for contracts? This needs to work for arbitrary complicated interactions, basically anything I can sign and submit.
I have a fully synced node, so everything can be done locally.
Ganache in-memory Ethereum testnet supports forking a mainnet.
Ganache allows you to "unlock" any Ethereum account, so you do not need to have necessary private keys to sign transactions to simulate actions.
late answer but I recently had this problem and so I've developed a tool to solve it.
You can simulate Ethereum transactions on the mainnet with Pelta Shield.
This tool allows you to see the usual tx info (such as what you would see on Etherscan) before the transaction actually gets included in a block.
In fact you can even abort the simulated transactions if you don't like the result of it, and you will not pay any gas.
Note that the results of the simulation will only be accurate as long as the transaction doesn't depend too much on the live state of the Ethereum blockchain.
If the state of the blockchain changes between the simulation and the actual execution, the simulation may not accurately reflect the result of the transaction.
DISCLAIMER: I am the founder of Pelta.tech, the startup that developed Pelta Shield, so I'm definitely biased in my recommendation.
How can I update the smartcontracts of my Truffle dapp which are deployed in the Ethereum blockchain?
Great answer found here.
From axic in Ethereum Stack Exchange site:
Contract code is immutable, the storage is mutable, but you cannot
execute code placed into storage, at least for now.
Bugfixes to contracts
As for bugfixes, the common pattern is to have proxy or lookup
contracts to be a gateway to the real one, which in case of a change
or bugfix would be replaced. Replacing it also means losing the old
storage contents.
Keeping storage
If you want the ability to upgrade code, while keeping storage, you
could think of separating storage and logic. Have a dedicated storage
contract, which accepts write calls from trusted addresses (e.g. the
logic contracts). All important storage should be associated with this
one.
Accessing storage after selfdestruct
As of today there is no real pruning implemented even in the case of
selfdestruct, but that should definitely come in the future. There are
several EIPs discussing this.
Even if pruning is implemented, it shouldn't happen in an instant and
you should be able to read storage from the last state. It is also
planned to have archive nodes to keep states indefinitely -- not sure
that is feasible without limitations just by judging at the growth of
the blockchain.
Redeploying at same address
In short: practically this is not possible. The contract addresses are
calculated from the sender and the nonce. The nonce is sequential,
there cannot be any gaps and there cannot be duplicates.
In theory it is possible to arrive at the same hash with a different
nonce and address combination, but the likelyhood is small.
I am seeking Python 2.7 alternatives to ZeroMQ that are released under the BSD or MIT license. I am looking for something that supports request-reply and pub-sub messaging patterns. I can serialize the data myself if necessary. I found Twisted from Twisted Matrix Labs but it appears to require a blocking event loop, i.e. reactor.run(). I need a library that will run in the background and let my application check messages upon certain events. Are there any other alternatives?
Give nanomsg, a ZeroMQ younger sister, a try - same father, same beauty
Yes, it is licensed under MIT/X11 license.
Yes, REQ/REP - allows to build clusters of stateless services to process user requests
Yes, PUB/SUB - distributes messages to large sets of interested subscribers
Has several Python bindings available
https://github.com/tonysimpson/nanomsg-python (recommended)
https://github.com/sdiehl/pynanomsg
https://github.com/djc/nnpy
Differences between nanomsg and ZeroMQ
( state as of 2014/11 v0.5-beta - courtesy nanomsg.org >>> a-click-thru to the original HyperDoc )
Licensing
nanomsg library is MIT-licensed. What it means is that, unlike with ZeroMQ, you can modify the source code and re-release it under a different license, as a proprietary product, etc. More reasoning about the licensing can be found here.
POSIX Compliance
ZeroMQ API, while modeled on BSD socket API, doesn't match the API fully. nanomsg aims for full POSIX compliance.
Sockets are represented as ints, not void pointers.
Contexts, as known in ZeroMQ, don't exist in nanomsg. This means simpler API (sockets can be created in a single step) as well as the possibility of using the library for communication between different modules in a single process (think of plugins implemented in different languages speaking each to another). More discussion can be found here.
Sending and receiving functions ( nn_send, nn_sendmsg, nn_recv and nn_recvmsg ) fully match POSIX syntax and semantics.
Implementation Language
The library is implemented in C instead of C++.
From user's point of view it means that there's no dependency on C++ runtime (libstdc++ or similar) which may be handy in constrained and embedded environments.
From nanomsg developer's point of view it makes life easier.
Number of memory allocations is drastically reduced as intrusive containers are used instead of C++ STL containers.
The above also means less memory fragmentation, less cache misses, etc.
More discussion on the C vs. C++ topic can be found here and here.
Pluggable Transports and Protocols
In ZeroMQ there was no formal API for plugging in new transports (think WebSockets, DCCP, SCTP) and new protocols (counterparts to REQ/REP, PUB/SUB, etc.) As a consequence there were no new transports added since 2008. No new protocols were implemented either. The formal internal transport API (see transport.h and protocol.h) are meant to mitigate the problem and serve as a base for creating and experimenting with new transports and protocols.
Please, be aware that the two APIs are still new and may experience some tweaking in the future to make them usable in wide variety of scenarios.
nanomsg implements a new SURVEY protocol. The idea is to send a message ("survey") to multiple peers and wait for responses from all of them. For more details check the article here. Also look here.
In financial services it is quite common to use "deliver messages from anyone to everyone else" kind of messaging. To address this use case, there's a new BUS protocol implemented in nanomsg. Check the details here.
Threading Model
One of the big architectural blunders I've done in ZeroMQ is its threading model. Each individual object is managed exclusively by a single thread. That works well for async objects handled by worker threads, however, it becomes a trouble for objects managed by user threads. The thread may be used to do unrelated work for arbitrary time span, e.g. an hour, and during that time the object being managed by it is completely stuck. Some unfortunate consequences are: inability to implement request resending in REQ/REP protocol, PUB/SUB subscriptions not being applied while application is doing other work, and similar. In nanomsg the objects are not tightly bound to particular threads and thus these problems don't exist.
REQ socket in ZeroMQ cannot be really used in real-world environments, as they get stuck if message is lost due to service failure or similar. Users have to use XREQ instead and implement the request re-trying themselves. With nanomsg, the re-try functionality is built into REQ socket.
In nanomsg, both REQ and REP support cancelling the ongoing processing. Simply send a new request without waiting for a reply (in the case of REQ socket) or grab a new request without replying to the previous one (in the case of REP socket).
In ZeroMQ, due to its threading model, bind-first-then-connect-second scenario doesn't work for inproc transport. It is fixed in nanomsg.
For similar reasons auto-reconnect doesn't work for inproc transport in ZeroMQ. This problem is fixed in nanomsg as well.
Finally, nanomsg attempts to make nanomsg sockets thread-safe. While using a single socket from multiple threads in parallel is still discouraged, the way in which ZeroMQ sockets failed randomly in such circumstances proved to be painful and hard to debug.
State Machines
Internal interactions inside the nanomsg library are modeled as a set of state machines. The goal is to avoid the incomprehensible shutdown mechanism as seen in ZeroMQ and thus make the development of the library easier.
For more discussion see here and here.
IOCP Support
One of the long-standing problems in ZeroMQ was that internally it uses BSD socket API even on Windows platform where it is a second class citizen. Using IOCP instead, as appropriate, would require major rewrite of the codebase and thus, in spite of multiple attempts, was never implemented. IOCP is supposed to have better performance characteristics and, even more importantly, it allows to use additional transport mechanisms such as NamedPipes which are not accessible via BSD socket API. For these reasons nanomsg uses IOCP internally on Windows platforms.
Level-triggered Polling
One of the aspects of ZeroMQ that proved really confusing for users was the ability to integrate ZeroMQ sockets into an external event loops by using ZMQ_FD file descriptor. The main source of confusion was that the descriptor is edge-triggered, i.e. it signals only when there were no messages before and a new one arrived. nanomsg uses level-triggered file descriptors instead that simply signal when there's a message available irrespective of whether it was available in the past.
Routing Priorities
nanomsg implements priorities for outbound traffic. You may decide that messages are to be routed to a particular destination in preference, and fall back to an alternative destination only if the primary one is not available.
For more discussion see here.
TCP Transport Enhancements
There's a minor enhancement to TCP transport. When connecting, you can optionally specify the local interface to use for the connection, like this:
nn_connect (s, "tcp://eth0;192.168.0.111:5555").
Asynchronous DNS
DNS queries (e.g. converting hostnames to IP addresses) are done in asynchronous manner. In ZeroMQ such queries were done synchronously, which meant that when DNS was unavailable, the whole library, including the sockets that haven't used DNS, just hung.
Zero-Copy
While ZeroMQ offers a "zero-copy" API, it's not true zero-copy. Rather it's "zero-copy till the message gets to the kernel boundary". From that point on data is copied as with standard TCP. nanomsg, on the other hand, aims at supporting true zero-copy mechanisms such as RDMA (CPU bypass, direct memory-to-memory copying) and shmem (transfer of data between processes on the same box by using shared memory). The API entry points for zero-copy messaging are nn_allocmsg and nn_freemsg functions in combination with NN_MSG option passed to send/recv functions.
Efficient Subscription Matching
In ZeroMQ, simple tries are used to store and match PUB/SUB subscriptions. The subscription mechanism was intended for up to 10,000 subscriptions where simple trie works well. However, there are users who use as much as 150,000,000 subscriptions. In such cases there's a need for a more efficient data structure. Thus, nanomsg uses memory-efficient version of Patricia trie instead of simple trie.
For more details check this article.
Unified Buffer Model
ZeroMQ has a strange double-buffering behaviour. Both the outgoing and incoming data is stored in a message queue and in TCP's tx/rx buffers. What it means, for example, is that if you want to limit the amount of outgoing data, you have to set both ZMQ_SNDBUF and ZMQ_SNDHWM socket options. Given that there's no semantic difference between the two, nanomsg uses only TCP's (or equivalent's) buffers to store the data.
Scalability Protocols
Finally, on philosophical level, nanomsg aims at implementing different "scalability protocols" rather than being a generic networking library. Specifically:
Different protocols are fully separated, you cannot connect REQ socket to SUB socket or similar.
Each protocol embodies a distributed algorithm with well-defined prerequisites (e.g. "the service has to be stateless" in case of REQ/REP) and guarantees (if REQ socket stays alive request will be ultimately processed).
Partial failure is handled by the protocol, not by the user. In fact, it is transparent to the user.
The specifications of the protocols are in /rfc subdirectory.
The goal is to standardise the protocols via IETF.
There's no generic UDP-like socket (ZMQ_ROUTER), you should use L4 protocols for that kind of functionality.