It has been awhile since we wrote any news on MixBytes, and we need to update the status. Over the past 1–2 months, MixBytes has been engaged in the following projects:

1. EOS smart contract constructor in Smartz

Our flagship project Smartz stated that one of the key features of its platform is associated with the use of several blockchains. We had to stand by our word, and therefore 80% of the development resources were involved in EOS. Smartz EOS smart contract constructor provides EOS smart contract developers with the ability to create a template and allow users to self-publish their own template-based contracts to the EOS network, i.e. everything is just like in Ethereum. But in the course of implementation, we had to solve a ton of problems: we had to connect Scatter (an extension for EOS, such as MetaMask for Ethereum) to the Platform, deploy nodes on the test network and try to guess the mainnet, as well as to build the infrastructure for this and enable smart contract compilation (this is a much more interesting task for smart contracts that are based on C++ instead of Solidity). In general, we had a lot of work, both for the front end and the back end of Smartz and for researchers, as we tried a bunch of different engines and studied a lot of code. As a result, the first contract (for the token) in EOS is already ready to use, and now you can launch own token in just a couple of minutes. EOS does not have a clearly defined mainnet yet, so it is not clear where to deploy, but we are monitoring this situation (see below).

2. EOS block producer

Smartz has to communicate reliably with the EOS blockchain, so we need a reliable infrastructure of EOS nodes. Engine updates can be released twice a day; in addition, we need nodes in both mainnet and testnet. All this is similar to the tasks that a block producer solves in the network, so we decided to become a candidate for the role of an EOS BP in Russia. There are several dozen block producers (21 primary producers) who publish blocks on the EOS network and receive EOS tokens for this (like miners in Bitcoin). EOS token holders vote for producers. In this regard, we learned how to dockerize and deploy EOS nodes for any network, as well as quickly update the software on them, perform disaster recovery, etc. First of all, we took an honourable place among the top block producers in the Jungle Testnet where our servers are marked as Organisation: MixBytes.io. We collected a lot of votes in the test network and managed to strengthen our positions there. As for the production network, the situation is worse because crypto millionaires do not vote for us. In fact, we do not know any of them, and at the moment we just do not have time to look for them and negotiate in person. So for now, we are just keeping our node in the mainnet (it is mandatory for Smartz), but we are ready to become a BP at any time if suddenly there are people who want to vote for us.

3. Merkle-acl contracts for Ethereum and EOS

Many customers ask us about airdrop. We hate the version of airdrop that involves just sending tokens using a script and a mailing list; it is simply spam. In addition, there is a problem associated with providing a group of users with access to any specific function in the contract, as it would be wrong to save the list of those authorised addresses in the contract itself. In addition, if there are 10,000 addresses, this option is simply not feasible. Therefore, the contract requires the user (on his/her JS) to prove that he/she is on the list. This approach is suitable for some tasks, but the best illustration of its effectiveness is the kind of airdrop that let users "issue" tokens to themselves. Therefore, we first programmed the smart contract using Solidity and then tried to create an analogue for EOS. At the moment, only the contracts themselves are ready to use, and we have yet to develop Smartz constructors for them. So now, we are working on the Solidity-based version for Smartz. There is a problem with saving the address list because it is quite a large file, and we want to save it correctly, so we are deploying an IPFS and thinking about how to provide users with access to the Platform in the most convenient way. In addition, we must protect our nodes from cluttering.

4. ERC721 token

Of course, it may seem strange that this "entity" is also considered as a token. In fact, it is simply the right of ownership to an arbitrary object in the blockchain. It is like mapping {address -> {[batch of mappings]}}. This method is great for creating collectibles in games, as well as for all sorts of documents. Therefore, our contract is focused on this approach. Of course, we are also slowly but surely integrating IPFS; we understand everything from a technical point of view, but there are issues with the policy for saving user data, and we are still discussing implementation options and trying them out on test servers.

5. Code audits

During the last two months, the situation with audits has been quite interesting, as we have received audit reports not for banal ICOs or tokens, but for several large-scale contract systems and the client code, so we had no time to get bored.

These are the main technical projects. As for research and custom projects in the MixBytes business plan, for now they are mainly focused on Smartz, as we must demonstrate all the promised opportunities now. The general trends are as follows:

• We offer cheap services to develop custom solutions based on Smartz smart contracts, and we urgently need real-life contract deployments on the network. We have reserved the right to choose from the proposals, as different tasks require different resources. Contact us if you need a prototype of any system. We will develop it extremely cheap, and your prototype will be fully functional in the blockchain at once.

• We already have a couple hundred deployments on the network, and a couple dozen of them are functioning in the Ethereum Mainnet (yay!!). We have already earned about a thousand dollars, and we are just happy that the platform is gradually beginning to be used! In the future, we need to figure out which solutions will be more popular, but so far, our statistics are so few that it is very difficult to discuss something specific. It is worth mentioning that users deploy different contracts, including voting, multisignature, and ICO tokens; however, of course, it is too early to talk about which of them are more popular.

• We are implementing a new significant part of the platform designed to store user files (images, documents and address lists), and so far we have chosen IPFS for this purpose due to the high degree of readiness. We are currently deploying test nodes and trying to make IPFS convenient for end users.

So, we have briefly described our current projects, and we hope that this post has to some extent managed to satisfy your hunger for information.