TxHash Network — Tech FAQ Friday

Since the release of our whitepaper, our community has grown from a few hundred to many thousands. This impressive growth has given us the opportunity to gain valuable feedback on the TxHash Network. A number of technical questions have come up a few times, which we’d like to address in this post.

We’re super thankful for all the feedback we receive from our community and encourage discussion in our telegram group.

While most of the questions here are technical, we will look at the other aspects of our SaaS and TxHash Network in our upcoming posts!

As a decent developer, why would I use TxHash rather than implement the solution in-house?

We built TxHash with the objective to help developers save time and focus on their own applications. Our architecture is platform agnostic — we have abstracted the core of our tracker to support a variety of protocols. We’ve also developed fail-safe, fault-tolerant recovery mechanisms to sync our tracking engine. While it might look trivial to sync a few addresses, once you actually start creating a BaaS, it becomes time-consuming to develop and maintain it. It is a problem of O(n*m) time complexity, n being the number of trackers that you iterate over, and m being the number of transactions you have on a certain blockchain, both increasing over time. It’s important to understand whether the number of trackers is bigger than the number of transactions on the blockchain (n > m), or the other way around — this is what shapes the way you design and maintain your tracking algorithm.

That being said, we also have specified an allocation on our roadmap for setting up a research team solely focused on understanding possible scaling solutions for our project. For the reputation system and other parts of our architecture, we don’t plan to reinvent the wheel, but to source from the most innovative solutions currently out there.

Aren’t light nodes perfectly secure for the purpose of monitoring DLT networks — why would you need costly full nodes for that?

In order to retrieve the full state of transactions (f.ex. bitcoind), you actually need to run a full node.

To prove this, simply run the following experiment: Try to get the sender address (or tx input address, not txhash) of an arbitrary transaction on bitcoind. Are you able to get the address with a node in prune state?

In the Bitcoin protocol, the inputs are returned as transactions, and you need to go back in history in order to get the output for which a transaction corresponds to the original input address.

In the Ethereum protocol, it’s even more critical to run a full node, as well as a modified version of a full node (to properly log internal events). If you’d like to get the state of internal transactions on smart contracts, you rely on a full node.

To build our BaaS, it was necessary to run full nodes — not only from a technical point of view, but also from the perspective of the ecosystem as a whole: the more people keep running light nodes, the more difficult and costly it becomes to sync the complete state of a particular blockchain, especially with an increasing blockchain size. Here’s an example of what happens when you actually miss to complete part of the blockchain. While you can certainly create headers with light nodes and still have functional blockchains, you cannot audit transactions if you miss complete block information.

How are you able to monitor a smart contract function?

We can monitor any smart contract function at Ethereum Virtual Machine (EVM) OPCODE level. We have been experimenting and working with a Go developer to customize our own version of Geth for this matter.

If you’d like to track a token transfer, you’re able to monitor a “write” by listening to a transaction that calls `transfer(address,uint256)` or `0xa9059cbb…`. This is trivial.

However, if you have a smart contract that implements a bulk mechanism to transfer tokens, someone would call instead `bulkTransfer(address,uint)` or `0x42854612…`. If that method calls the ERC20 transfer method internally, then tracking actually is not trivial at all, and again requires you to monitor the smart contract function at OPCODE level on the EVM.

But if you have a smart contract that, let’s say, implements a bulk mechanism to transfer tokens, someone would call instead `bulkTransfer(address,uint)` or `0x42854612…`. If that method calls internally the ERC-20 transfer method, then tracking it is not trivial, and again requires you to monitor things at OPCODE level on the EVM.

If you deliver a wrong event to a customer, and then someone checks the validity, you potentially lose part of your proof-of-stake deposit. However, your customer still received a wrong event and might execute wrong transactions behind that. How do you plan to solve this issue?

We are completely aware of this problem and are currently working on a strategy to mitigate this along with one of our tech advisors — Michael, the CTO of SignRequest, a well-known SaaS. We have been debating about a couple of options: from studying the TOR protocol to understanding TLS on a low-level to see how we could delegate API calls, in a trustless way.

While we already came up with some ideas to solve this, we have been directing our current research efforts towards other areas. With the fundraising, we would like to allocate a big amount of the collected funds to research on this particular topic along with expanding the team. With a growing and heavily research-focused team, we are absolutely confident to solve these issues in a timely manner.

Update on Token Sale

During the last 2 weeks we have received massive interest from funds and angels, we have been setting up our tech and legal infrastructure and today we are happy to announce that we are ready to start working with our first strategic partners!

Soon we will release our plans for our Pre Sale and Public Sale. If you are an accredited investor or fund, feel free to reach us for a potential cooperation here.

In the meantime, if you have more (technical or business related) questions around our project, feel free to join the conversation on Telegram, Reddit, and Twitter. We look forward to hearing from you!

***

Check out our website. Updates will be posted on our Blog, Telegram, Reddit, and Twitter. We welcome feedback from the community and are open to collaborations, so please get in touch.