further documentation of changes to the underlying SOILcoin protocols and Go-OS initialized by the upcoming hard forks, bringing our code base to near congruence with Ethereum's operational ability:
via the 1.5.0 release of go-ethereum:
*
Changes to the RPC API*
The behavior of
eth_sign is changed. It now accepts an arbitrary message, prepends a known message ["\x19Ethereum Signed Message:\n" + len(message)], hashes the result using keccak256, and then calculates the signature of the hash (breaking backwards compatibility). By adding a prefix to the message, this makes the calculated signature recognizable as an Ethereum-ecosystem specific signature. This prevents misuse where a malicious DApp can sign arbitrary data (e.g. transaction) and use the signature to impersonate the victim.
Added RPC calls related to this function include
personal_sign, which functions similarly to eth_sign but also accepts a password; and
personal_recover, which returns the address of the account that created the signature.
usage:
personal_recover(message, signature)
personal_sign(hash, address [, password])
Further, other added RPC functions are:
personal_importRawKey : import an unencrypted private key via RPC.
eth_getRawTransaction : returns the RLP encoding of a transaction.
debug_traceTransaction : run a transaction via debugging in the exact same manner as it was executed on the network. Alongside the transaction hash, optional secondary arguments can be specified:
disableStorage: BOOL. Setting this to true will disable storage capture (default = false).
disableMemory: BOOL. Setting this to true will disable memory capture (default = false).
disableStack: BOOL. Setting this to true will disable stack capture (default = false).
fullStorage: BOOL. Setting this to true will return you, for each opcode, the full storage. This is a slow process. (default = false)
tracer: STRING. Setting this will enable JavaScript-based transaction tracing. If set, the previous four options will be ignored. JavaScript-based tracing enables the user to evaluate an object with (at least) two methods, named
step and
result. Step is a function that takes two arguments,
log and
db, which are called for each step of the EVM, as the specified transaction is traced.
The log contains the following fields:
pc: Number, the current program counter
op: Object, an OpCode object representing the current opcode
gas: Number, the amount of gas remaining
gasPrice: Number, the cost in wei of each unit of gas
memory: Object, a structure representing the contract's memory space
stack: array[big.Int], the EVM execution stack
depth: The execution depth
account: The address of the account executing the current operation
err: If an error occured, information about the error
db has the following methods:
getBalance(address) - returns a big.Int with the specified account's balance
getNonce(address) - returns a Number with the specified account's nonce
getCode(address) - returns a byte slice with the code for the specified account
getState(address, hash) - returns the state value for the specified account and the specified hash
exists(address) - returns true if the specified address exists
timeout: STRING. Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Optional string values are discussed at length in the go language documentation at
https://golang.org/pkg/time/#ParseDurationUSAGE:
Go: debug.TraceTransaction(txHash common.Hash, logger *vm.LogConfig) (*ExecutionResurt, error)
Console: debug.traceTransaction(txHash, [options])
RPC: {"method": "debug_traceTransaction", "params": [txHash, {}]}
Features added into the 1.5.0 (Let There Be Light) release, but flagged as "experimental" but show the sorts of functions that are being added into the performance of the SOILnet EVM which will allow us to build bigger and better applications going forward. Naturally we will maintain observation of code-releases from Ethereum Core, and when these features are stablized we will document them further, but as of yet, I havent had the chance to test them on the SOILnet, it is simply nice to know that these attributes are becoming available. Typical caeat... use these features at your own risk.
*gsoil will be enabled to run in
Light Client mode with the
--light flag. Light client mode syncs recent block headers and fetches state values on demand. NOTE: light client servers will need to be first made available. Users can set up as a light-client server using the
--lightserv flag. A light server is a full node with "LES server" option enabled. i.e:
allocates 25% of CPU power towards providing a Light Client Server
The purpose of the Light Ethereum Subprotocol (LES) protocol is to allow users in low-capacity environments (embedded "smart property" environments [eg: an object which hosts an externally-owned account or a contract account], IoT enabled devices, smartphones, browser extensions, older desktop computers and laptops, etc) to maintain high-security assurances regarding the current state of user-defined part of the SOILnet state or to verify the execution of transactions and smart contract operations. Light Clients do not run a full node, but can receive data from the network.
Light Clients will be able to perform many operations: requests regarding the state of an account (nonce, balance, code or storage index), requests regarding transaction confirmations (within consumer-merchant scenarios), request block validations or set to watch for and log blockchain events, which is useful where a dApp needs to keep track of certain events that are nt part of the permanent state of the platform but need to be verifiable in an efficient manner, such as a decentralized exchange logging trades or internal wallet transactions.
Light Clients will also make cross-chain inter-operability much more feasible. As SOILcoin maintains a Bitcoin Light Client in the operation of the BTCrelay application, which allows a SOILnet resident smart contract to request verification of transactions occuring on the BTC blockchain to enable state changes (value transactions) on the SOILcoin blockchain, a SOILcoin Light Client may make it easier for other currencies to also build relays to SOILcoin, especially alt-etherea Dagger based currencies.
There are limitations to what the light client can do presently. The only pending transactions a light client knows about are the ones that have been
created and
sent from that client. Likewise, locally created transactions can only be found by searching for it's hash. Finding other transactions is a bit trickier. Searching for events (transactions) in a long blockchain history will take an extremely long timeas searches are only performed in individual headers, rather than using a MIP-mapped filter as full clients use to search, in a faster and cheaper manner.
The advantages of Light Clients is that they take up far less disk space to maintain their database, allowing it the ability to sync in minutes, but nonetheless fully interacts with the SOILcoin blockchain, and is usable through the DUST browser for SOILsafe.
*The
Swarm daemon (
bzzd) and associated helper tools are included with the latest go-soil builds and are somewhat functional. SWARM is the EVM protocol designed for
decentralized file storage. The release included with go-soil is considered a Proof-of-Concept implementation of the Swarm protocol. It is included as a separate daemon process (and inherently executable binary), not embedded inside gsoil.
The objective of Swarm is to provide a decentralized store of and distribution channel for dApp code and data as well as other user defined data. Participants will be able to efficiently pool storage and bandwidth resources to provide these as services to other participants as an on-chain P2P data-storage and data-serving protocol that is DDOS-resistant, and which thanks to the underlying SOILcoin blockchain, maintains "zero-downtime" (data delivery would be based upon average block times), and is designed to be self-sustaining with a built-in incentivization system which leverages p2p accounting, permitting the exchange of resources (storage space, bandwidth) for payment.
Swarm will, as a native base layer of the SOILcoin web three stack, continue to evolve its services and implementations, and dApps are already appearing to leverage this technology: album - a photo album dapp with a set of public-domain photographs that lets users upload their own photos; and filemanager - a GUI explorer for file collections hosted on the swarm.
Swarm is designed to deeply integrate with the devp2p multiprotocol network layer of SOILcoin, as an alt-etherea currency, as well as with the SOILcoin blockchain for application services (domain name registration, payments for services, etc). Naturally, as this is rolled onto the SOILcoin network and tested, we will endeavor to provide much more in-depth documentation regarding its usage, and how to set up Swarm clients for both sides of the economic model, as well as ensure swarm-dApps a
Ive followed the Swarm project as it has moved towards implementation within go-ethereum, and this will be one of the projects getting a lot of my attention over the next few months as its integration onto the network layer of SOILcoin becomes hardcoded. The project is running smoothly on the Ethereum blockchain, and is actually
hosting its own homepage, at:
http://swarm-gateways.net/bzz:/1b5d887cea699d18560ae6dcaf06676f5064f630978b8031d9beb6fbddd82a82SWARM was touted as one of the three cornerstones to the EVM, and as you can see, can also be used to deliver a decentralized web via
serverless content hosting, with support for browsing directly integrated within the DUST wallet for SOILsafe when we follow ETH into Metropolis. There is a TON of documentation for swarm, and thatll definitely have to be another day.
*
Whisper v5 PoC code is included in the repository, but not enabled yet. Whisper protocols will enable not only users to communicate with each other, but for contracts to communicate with other contracts. Whisper is considered the third cornerstone to a decentralized internet, and has many use cases: a decentralized exchange dApp may use Whisper to broadcast an offer to sell an asset at a specific rate, and could advertise this for a set amount of time, from several minutes minutes to days. Some dAppswill require signals from eachother in order to ultimately collaborate on a transaction. Whisper can be used to build chat-rooms, or to provide "dark communications" between two parties that have no knowledge of eachother beyond a hash, with source and destination hidden from both parties, and may also leverage Swarm for file transfers initiated from Whisper chats.
As with Swarm, there is a ton of documentation for the usage of Whisper, and as it is made more available for usage, we will endeavour to provide those sorts of guides for both Whisper and Swarm on go-soil. The Whisper overview on the Ethereum wiki is a good place to start to understand how to interact with Whisper (
https://github.com/ethereum/wiki/wiki/Whisper-Overview) but we'll try to include this sort of information when Whisper implementation is fully realized.
*go-ethereum is able to be used as a library in Android (Java) and iOS (ObjC/Swift) projects with the 1.5.0 code release. abigen, discussed in a previous post, has gained preliminary support for creating Java bindings to EVM-level smart contracts. this may make running full node or light clients on Android and iOS devices much more attainable, and again, opens up interactivity for building projects such as the DUST wallet for SOILsafe on a smart phone, allowing for dApp interaction, file storage and service thru Swarm or anonymous messaging thru Whisper.
essentially a lot of the changes reflected in the newer code changes to Ethereum which we are upgrading SOILcoin to are providing the architecture needed to begin building those sorts of distributed applications for the industries we indentified as underserved and most likely to benefit from the sort of decentralized services our blockchain will be able to offer at a exponentially smaller cost than current models of cloud service delivery, or virtual hosting needs.
capitalizing on these advantages over the next few years will be what sets SOILcoin aside from other projects, and these evolutionary adjustments to what we can offer brings the IDEA of what the SOILnet can offer more than a few steps closer. theres a lot of work to be done, but every step made makes the SOILnet that much more accessible and readily available, even to users who wont even realize they are interacting with it (decentralized webpages), which is the ultimate idea behind a decentralized web.
more to come, as ETH wasnt done improving their codebase, and those changes reflect to how the SOILnet operates, and what it is capable of. honestly, the tools we are making available EXCITE me, almost as much as when hearing about Ethereum for the first time somewhere near two years ago and getting involved on their test-net. this project has for a long time been about the possibilities of what we will be able to create and offer, and i knew early on that it would take time for the underlying infrastructure to catch up with the ideas that were floating around my brain. we're getting there now, we're approaching that point where EVERYTHING changes, where this technology finally disrupts every industry, and with SOILcoin focused on delivering applications that will ultimately serve to make this planet not only more efficient, but healthier and greener, we stand on the precipice of an age where every one of us can make a difference, where true collaboration without censorship can be achieved.
ive always been a somewhat utopian thinker, and realized early that blockchain technology.. extraspecially the EVM.. was going to be the game changer that alters society, and that adoption of these sorts of technology is a very exponential curve, we're still... 18 months after the genesis of the SOILnet... at the base of this curve, and we're still alive and... well... BLOCKING. i think we are better prepared to ride this wave than a lot of other alt-etheria, more so because i believe we have a better vision towards the scale of how big this can get, in a practical sense. hopefully with these sorts of changes, we can position ourselves to make some noise in the crypto world finally....
- here is gsoil 1.6.1! based on the very latest go-ethereum sourcecode. This is a huge step compared to our current client, having now all the latest improvements included to gsoil. Believe me, that was not easy - keep in mind that I'm not a developer. Anyway here you go: https://github.com/Soilcoin/go-soil