Sharing weather data autonomously using Fetch.ai — Part 2

Nov 13, 2019

In the first part of this series of articles, we discussed how agents find, connect and interact with each other. In our example, we outlined how an Autonomous Economic Agent (AEA or simply ‘agent’) discovered another agent that represented data (in this case the weather in London) and negotiated a price (i.e. a fraction of a cent) that it was willing to pay in return for the information.

Now, let’s take a look at how the agents transact across Fetch.ai’s smart ledger. If the ledger didn’t exist, agents would need to blindly trust that each other would fulfill their obligations honestly. They would also need to rely on mechanisms outside of their native environment of the Fetch.ai network in order to settle transactions (e.g. by bank transfer). Clearly, this would be far from ideal, as it would be unlikely to be worthwhile completing the transaction. This is because the micropayment that would be exchanged between the agents in return for the weather data would be less than the cost of the bank transfer itself.

Fetch.ai is extremely proud of its world class smart ledger, which is capable of handling 30,000 transactions per second. In our example, the agent representing the weather station would not need to trust Charlotte’s agent to know that it would receive the agreed micropayment. This is because the agent representing the weather station would be able to observe transactions taking place on the public ledger. The selling agent would receive a receipt from the purchasing agent, allowing it to verify that the transaction is complete. Once it has done so, it would send the agreed data to Charlotte’s agent. However, while this reduces the risk for the weather station agent, this doesn’t resolve the trust issues facing Charlotte’s agent. Her agent can only see the data once the micropayment has been made, meaning it has to trust that the weather station agent will fulfill its side of the bargain. As a result, Charlotte’s agent runs the risk of being shortchanged if the weather station agent sends insufficient data.

Therefore this approach doesn’t provide a solution to all of the complex trust issues. Charlotte’s agent not only needs to trust that the agent representing the weather station is sharing data, but that the data it is sharing contains accurate information about the weather.

In the next article in this series, we’ll examine how Charlotte’s agent can lower the amount of trust it must place on the weather station agent. By ensuring agents can trust one another, we can empower them to reliably conduct useful economic activity in real time and successfully avoid negotiating with agents who act with bad intentions.

Get involved