Tag Archive for: techinplatformslider

Open Source Monday: zk-SNARKs for Meter Data

For the fourth installment of our “Open Source Monday” blog series, we provide a demonstration of a mathematical proof called zk-SNARK (an emerging Web3 standard) for energy data.

Today’s Open Source Monday blog is the culmination of a number of previous Web3 open source releases and blog posts.

First, frequent blog readers will know that we’re long-time believers in the potential of Web3 and it’s ability to accelerate the adoption of clean energy. Our blogs below make that clear:

These blog posts are in line with VIA’s mission to make communities cleaner, safer, and more equitable.

Second, we’ve been committed to creating the best tech stack that (1) supports the transition to clean energy and, at the same time, (2) maintains data privacy:

Finally, it’s clear that the “time is now” for the clean energy transition.

So, now that you’re caught up on the importance of Web3 at VIA, let’s get to the good stuff.

Today, we’re demonstrating a zk-SNARK version of our proof for meter data. For those zk-SNARK fans out there, we’ve got a short video for you that shows step-by-step the contracts and code we have created to verify consumer electricity meter data and maintain strict data privacy.

With the integration of this proof, VIA’s Skylight application enables energy consumers to profit from interest in their data, while keeping their identities completely anonymous. We’re excited that Skylight is ready to support consumers and power providers globally. Stay tuned for more exciting commercial announcements in the next month on this topic. In the meantime, you can find more details in our Skylight white paper.

Open Source Monday: How to Spot Malware in Your NFT

Like the internet and GPS that we use every day, VIA’s data privacy and security platform was first tested at scale by the U.S. Department of Defense.

A major U.S. intelligence agency has been actively testing the ability of VIA’s blockchain platform to detect potential cyber threats to data sources. 

We can’t disclose much that we did in detail. Actually, we can’t disclose anything in detail. After six months and well over 350 tests, there is one insight, however, that we feel is important to share publicly:

It’s ridiculously easy to inject malware into a file that can then be downloaded as an NFT!

As NFTs have exploded in popularity (23% of millennials in the U.S. collect them), adding malware to an NFT is an easy and fast way for malicious users to spread chaos.

So, today, VIA is making a malware check for NFTs code available for free, for anyone: https://github.com/viascience/nftscan. Special thanks to the steganography open source community for their help to create this NFT vulnerability scanner.

This initial version on GitHub has three separate malware checks. There are instructions on how to submit a pull request for you to add your own additional malware checks. If you’re interested in using the code on your website, write to us at info@solvewithvia.com

Want to learn more about how hidden text and malware code can be easily transferred when not checked? Watch this 43 second video.

If you’re interested in making the NFT community safer, please share this blog with your networks!

Stay safe out there everyone!

Let’s TAC™ About It: Verified Templates: Balancing Security and Flexibility

For the tenth installment of our blog series, we will cover how TAC™ contracts can control what kinds of queries an analyst can ask. So, are you ready to TAC™ about it?

In our last Let’s TAC™ About It blog post, we gave a brief overview of how smart contracts work in TAC™. In addition to timing and user role, TAC™ contracts can also control what kinds of queries an authorized analyst can ask of the data. Arguably, this is the most unique and valuable feature in TAC™. 

We have three methods. On one extreme, TAC™ can do this through Verified Scripts. This provides strong data control but limited analyst flexibility. Any analysis code is reviewed and pre-approved. The limitation is that this requires a manual review and approval process for each script. This is most useful for common and frequently performed analysis. VIA provides a number of Verified Scripts (e.g., descriptive statistics like max, min, etc.) by default.

On the other extreme, we have Free Form Python (FFPy). In this scenario, anything an analyst can ask in Python code (including “send me all the data” kind of queries) is permitted. This is terrific for analyst flexibility but has limited data protection for Data Owners (DOs). Internal power users are the main audience for this method.

What if you need something in-between? This is the most common scenario and hardest to solve for. 

Here, TAC™ uses Verified Templates (VTs). DOs use VTs to set boundaries about what analysts can and cannot do. Within those boundaries, analysts have great flexibility. In short, each VT has two parts. The “end of a Python module” is written or agreed to by the DO and sets the boundaries. It is immutable. The second part, the header of the module, is filled in by the analyst. The VT can even include variables that are not defined. These provide entry points that must be fully defined to control the workflow before running. Any file where the end of the Python module matches the VT exactly (other than newlines and comments), constitutes a validated instance of the template. 

This is an example VT:

def main(db, tables, results_path):
   return []

The variable hello_world is highlighted because it is not defined by the template, thus providing flexibility to an analyst.

Then, the following query is a valid instance of the template:

hello_world='Welcome to TAC!'
def main(db, tables, results_path):
   return []

and the following query is an invalid instance of the template:

def main(db, tables, results_path):
   print('Welcome to TAC!')
   return []

As this example shows, the VT must include the main function. Once an analyst changes the body of the main function or any other functions defined in the template, their query will be rejected by TAC™ and not sent to a DO’s data to run.

Sophisticated DOs can create an infinite number of VTs to suit their specific needs. VIA also has predefined VTs for specific use cases such as 15/15 for utility meter data analysis.

A hash of the DOs VT is stored in the smart contract and must be verified to execute. The VTs themselves can be stored on or off the blockchain. A combination of off-chain VT storage and on-chain hash is a common practice for privacy reasons. 

Customers have been testing VTs on TAC™ for the past few months and we have been very pleased with the results so far. Balancing security and flexibility is a hard but universal challenge. We’re excited to have found a relatively high performance solution for the utility industry.