Skip to content

Commit e36c476

Browse files
MadisonwMadisonw
committed
updating the readme, and the draw png/source
1 parent f73dd0d commit e36c476

File tree

3 files changed

+64
-41
lines changed

3 files changed

+64
-41
lines changed

‎lib/allora/README.md

Lines changed: 34 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
| Contributed by |
44
|:--------------------:|
5-
| [@clementupshot](https://github.com/clementupshot), [@allora-rc](https://github.com/allora-rc) |
5+
| [@clementupshot](https://github.com/clementupshot), [@allora-rc](https://github.com/allora-rc), [@Madisonw](https://github.com/Madisonw)|
66

77
[Allora](https://www.allora.network/) is a self-improving decentralized Artificial Intelligence (AI) network. The primary goal of the network is to be the marketplace for intelligence. In other words, Allora aims to incentivize data scientists (workers) to provide high-quality inferences as requested by consumers. Inferences include predictions of arbitrary future events or difficult computations requiring specialized knowledge.
88

@@ -31,26 +31,52 @@ The AWS Cloud Development Kit (CDK) is used to deploy a single Allora Worker Nod
3131
- Public subnet that has a direct route to the IGW
3232
- Security Group (SG) with TCP Port 9010 open inbound allowing requests for inferences to be routed to the Allora Worker Node
3333
- Single Amazon Elastic Compute Cloud (EC2) instance (the Allora Worker Node) assigned to the public subnet
34-
- Elastic IP Address (EIP) associated with the EC2 instance to maintain consistent IP addressing across instance restarts
3534

3635
The Allora Worker Node is accessed by the user internally and is not exposed to the Internet to protect the node from unauthorized access. A user can gain access to the EC2 Instance using AWS Session Manager.
3736

3837
Multiple processes run on the Allora Worker Node (EC2 instance):
3938

40-
- Docker container with the worker node logic that handles communnication bet
41-
- Docker container running the model server that reveal inferences to consumers
39+
- Docker container with the worker node logic that handles communication between the worker and the public head nodes
40+
- Docker container running the model server that reveals inferences to consumers
4241

4342
Allora Public Head Nodes publish the Allora chain requests (requests for inferences from consumers) to Allora worker nodes. When a worker node is initialized, it starts with an environment variable called BOOT_NODES, which helps handle the connection and communications between worker nodes and the head nodes.
4443

45-
The worker node (docker container) will call the function that invokes custom logic that handles. The request-response is a bidirectional flow from the Allora chain (inference requests from consumers) to the public head nodes to the worker node and finally to the model server that reveals inferences.
44+
The worker node (docker container) will call the function that invokes custom logic that handles the actual inference. The request-response is a bidirectional flow from the Allora chain (inference requests from consumers) to the public head nodes to the worker node and finally to the model server that reveals inferences.
4645

46+
## Additional materials
47+
48+
<details>
49+
50+
<summary>Well-Architected Checklist</summary>
51+
52+
This is the Well-Architected checklist for the Allora worker nodes implementation of the AWS Blockchain Node Runner app. This checklist takes into account questions from the [AWS Well-Architected Framework](https://aws.amazon.com/architecture/well-architected/) which are relevant to this workload. Please feel free to add more checks from the framework if required for your workload.
53+
54+
| Pillar | Control | Question/Check | Remarks |
55+
|:------------------------|:----------------------------------|:---------------------------------------------------------------------------------|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
56+
| Security | Network protection | Are there unnecessary open ports in security groups? | Please note that port 9010 (TCP) is open inbound to support requests for inferences from the Allora Network public head nodes. |
57+
| | | Traffic inspection | Traffic protection is not used in the solution. [AWS Web Applications Firewall (WAF)](https://docs.aws.amazon.com/waf/latest/developerguide/waf-chapter.html) could be implemented for traffic over HTTP(S), [AWS Shield](https://docs.aws.amazon.com/waf/latest/developerguide/shield-chapter.html) provides Distributed Denial of Service (DDoS) protection. Additional charges will apply. |
58+
| | Compute protection | Reduce attack surface | This solution uses Amazon Linux AMI. You may choose to run hardening scripts on it. |
59+
| | | Enable people to perform actions at a distance | This solution uses [AWS Systems Manager for terminal session](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-sessions-start.html#start-sys-console). SSH Port 22 is not open inbound. |
60+
| | Data protection at rest | Use encrypted Amazon Elastic Block Store (Amazon EBS) volumes | This solution uses encrypted Amazon EBS volumes. |
61+
| | Authorization and access control | Use instance profile with Amazon Elastic Compute Cloud (Amazon EC2) instances | This solution uses AWS Identity and Access Management (AWS IAM) role instead of IAM user. |
62+
| | | Following principle of least privilege access | Root user is not used (using special user "ec2-user" instead). |
63+
| | Application security | Security focused development practices | cdk-nag is being used with appropriate suppressions. |
64+
| Cost optimization | Service selection | Use cost effective resources | We use a T3 instance as T3 instances are a low cost burstable general purpose instance type that provide a baseline level of CPU performance with the ability to burst CPU usage at any time for as long as required. T3 instances are designed for applications with moderate CPU usage that experience temporary spikes in use. This profile aligns closely with the load profile of Allora Network worker nodes. |
65+
| Reliability | Resiliency implementation | Withstand component failures | This solution does not use an [AWS EC2 Auto Scaling Group](https://aws.amazon.com/ec2/autoscaling/) but one can be implemented. |
66+
| | Data backup | How is data backed up? | Considering blockchain data is replicated by Allora Cosmos AppChain Validator nodes, we don't use additional mechanisms to backup the data. |
67+
| | Resource monitoring | How are workload resources monitored? | Resources are not being monitored using Amazon CloudWatch dashboards. Amazon CloudWatch custom metrics are being pushed via CloudWatch Agent. |
68+
| Performance efficiency | Compute selection | How is compute solution selected? | Compute solution is selected based on best price-performance, i.e. AWS EC2 T3 Medium instance suitable for bursty workloads. |
69+
| | Storage selection | How is storage solution selected? | Storage solution is selected based on best price-performance, i.e. Amazon EBS volumes with optimal IOPS and throughput. |
70+
| | Architecture selection | How is the best performance architecture selected? | A combination of recommendations from the Allora Network community and Allora Labs testing. |
71+
| Sustainability | Hardware & services | Select most efficient hardware for your workload | The solution uses AMD-powered instances. There is a potential to use AWS Graviton-based Amazon EC2 instances which offer the best performance per watt of energy use in Amazon EC2.
72+
</details>
4773

4874
## Worker Node System Requirements
4975

5076
- Operating System: Any modern Linux operating system
51-
- CPU: Minimum of 1/2 core
52-
- Memory: 2 to 4 GB
53-
- Storage: SSD or NVMe with at least 5GB of space
77+
- CPU: Minimum of 2 cores
78+
- Memory: Minimum of 4GB
79+
- Storage: SSD or NVMe with minimum of 20GB of space
5480

5581
## Setup Instructions
5682

0 commit comments

Comments
 (0)