Patrol's mission started after the Bittensor summer attacks where we saw $20M+ stolen from TAO holders, members of our Bittensor community.
Our mission, simply put, is to secure crypto funds and provide all holders peace of mind, wherever they are.
Patrol is our first step in harnessing Bittensor to collect large volumes of live data which in later stages will be analyzed and used to prevent hacks.
In Patrol, miners and validators work together to intelligently collect large volumes of data from various data sources. It lays the foundation for advanced security intelligence by creating a knowledge graph that maps relationships and behaviours, aiding in investigations, threat detection, and risk assessment.
The first data source we’re covering is in our own backyard: The Bittensor chain. But this is just the beginning as we plan to expand to many other chains as well as other types of data sources like social media, code repos, phishing websites, and more. Ultimately, our goal over time is to build a unified graph of relationships for every crypto wallet that shows all its relationships.
One of the key lessons from the Bittensor summer attacks is that tracing footprints after the fact takes A LOT of time and is VERY costly. And when it comes to crypto theft investigation, time is of the essence. The longer it is from time of attack the less likely one is to recover funds.
The footprint graph that Patrol creates is a must-have for any security team, investigator and platform developing and solving crypto security.
Soon after Patrol launches we plan to provide a Public API for developers interested in consuming the data collected by the Patrol subnet.
The flow of the subnet begins with validators selecting target wallets to submit to miners. These targets are randomly selected from the chain. The validator then sends a target to each miner. See full target selection code here
Miners receive the target from the validator and begin their search for related data. Miners construct a subgraph of relational data for the target, and follow the data trace to expand their subgraph to N degrees of separation from the original target.
Example:
target = "5GWzwBegYVwZdRjQwaGAvktpGuYaeUYXnMaoaC5PPcqEBuW2"
target_block = 5100341
subgraph_generator = SubgraphGenerator(event_fetcher=fetcher, event_processor=event_processor, max_future_events=50, max_past_events=50, batch_size=50)
subgraph = await subgraph_generator.run(target, target_block)
print(subgraph)See the full miner processing class here.
The subgraph that miners submit is composed of:
- Nodes: Representing the entities in the subgraph (wallets, etc)
- Edges: Representing relationships between nodes like transactions and staking (exapnding to include parent-child relationships as part of the roadmap).
- Evidence: Supporting data to verify the nodes and edges
These subgraphs are then submitted to the validator for evaluation.
Once miners submit their subgraphs, Validators will verify the data by checking the evidence against the node and edge data submitted by the miners. This validation is pass/fail, failing will result in a score of 0 for that submission. This verification process currently supports the following node and edges types:
Nodes:
- Wallet nodes: Contains wallet addresses and types.
Edges:
- Transaction edges: Direct token transfers between wallets
- Staking edges: Staking relationships between wallets
See here for more details on the supported node and edge types.
Once the data has been verified, validators will calculate a score for the miner based on the following criteria:
- Volume (90%): Amount of valid data submitted, with reasonable caps
- Responsiveness (10%): How quickly the miner can submit data
- Novelty (will be implemented soon) : How unique the data returned by the miner is.
volume = len(payload.nodes) + len(payload.edges)
volume_score = self.calculate_volume_score(payload)
responsiveness_score = self.calculate_responsiveness_score(response_time)
overall_score = sum([
volume_score * self.importance["volume"],
responsiveness_score * self.importance["responsiveness"]
])View detailed overview of incentive mechanism here.
Ultimately, the mission for each miner is to achieve the highest coverage score by delivering data that is high quality, high quantity, and novel. By doing so, miners ensure that only top-tier data is presented to validators, fortifying a comprehensive and dynamic knowledge graph. This invaluable resource is pivotal for a wide array of security applications, driving the future of digital asset protection and intelligence.
| Docs | Resources |
|
⛏️ Mining Guide 🔧 Validator Guide 📈 Incentive Mechanism |
🧠 Bittensor Introduction |
-
Addition of parent-child relationships to supported edge types
-
Support for additional data sources
- Ethereum chain
- Solana chain
- X (Twitter)
- Github repositories
-
Public API for querying the knowledge graph
-
Dashboard for tracking miner performance and metrics
This repository is licensed under the MIT License.
# The MIT License (MIT)
# Copyright © 2023 Tensora Holdings Limited
# Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated
# documentation files (the “Software”), to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software,
# and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
# The above copyright notice and this permission notice shall be included in all copies or substantial portions of
# the Software.
# THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
# THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
# OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.