layers draft

[prekucki]

No description provided.

[dopiera]

Reviewable status: 0 of 1 files reviewed, 22 unresolved discussions (waiting on @prekucki)

---

arch-snapshot/arch.md line 62 at r1 (raw file):
As much as (I think) I understand the intention, I'm afraid this is not understandable to the intended audience - we do not assume they know what Clay Golem was.

How about:

Golem Network's applications are unknown in advance. Therefore, based on past experience, a decision was made to design the architecture flexible enough to swap out key components. This resulted in a three-layer architecture.

Code quote:

The main problem with Golem Clay was the difficulty in adding new applications. Therefore, in this iteration, it was
decided to divide the system into layers.

The goal is to enable building various solutions and testing hypotheses based on mechanisms provided by the lower
layers.

---

arch-snapshot/arch.md line 66 at r1 (raw file):

### Core Network

A basic set of functionalities that allows building a decentralized application.

While this statement is true, I think we need something more specific, e.g.:
The Core Network is the lowermost layer and represents the core of Golem Network. It connects machines to form a decentralized network of independent agents trading resources. In particular, the following aspects of Golem Network fall into this layer:

---

arch-snapshot/arch.md line 71 at r1 (raw file):

 - Communication between nodes
 - Discovering offers in the network
 - Ability to negotiate a structure representing the contract description

The mechanics of negotiations (i.e. the structure and flow of Offers and counter-Offers, but not the negotiation strategies nor the semantics of what is being negotiated)

Code quote:

Ability to negotiate a structure representing the contract description

---

arch-snapshot/arch.md line 73 at r1 (raw file):

 - Ability to negotiate a structure representing the contract description
 - Ability to issue invoices
 - Ability to pay invoices

I think "Ability to issue invoices" can be misinterpreted to mean the invoices which IRS would honor. Can we change these two points to:

• Requesting payments for services
• Processing payments

Code quote:

 - Ability to issue invoices
 - Ability to pay invoices

---

arch-snapshot/arch.md line 74 at r1 (raw file):

 - Ability to issue invoices
 - Ability to pay invoices
 - Ability to transmit events leading to the start of contract execution

We're capitalizing the artifacts and are linking them to their respective sections (PTAL #104). Could you please do that with Nodes, Offers, Invoices, etc.?

Code quote:

 - Communication between nodes
 - Discovering offers in the network
 - Ability to negotiate a structure representing the contract description
 - Ability to issue invoices
 - Ability to pay invoices
 - Ability to transmit events leading to the start of contract execution

---

arch-snapshot/arch.md line 82 at r1 (raw file):

This layer is divided into fundamental areas:
 - **Identity**: Managing identity in the network. Provides other modules with access to keys identifying the node and an API permissions model.

I'm sorry but I don't understand this part.

Code quote:

API permissions model

---

arch-snapshot/arch.md line 83 at r1 (raw file):

This layer is divided into fundamental areas:
 - **Identity**: Managing identity in the network. Provides other modules with access to keys identifying the node and an API permissions model.
 - **Market**: Includes functions for searching for offers, broadcasting offers, negotiating contracts, contract registry, and notifications about the start and end of a contract.

I thought that Providers perform negotiations, not Yagnas.

Code quote:

negotiating

---

arch-snapshot/arch.md line 85 at r1 (raw file):

 - **Market**: Includes functions for searching for offers, broadcasting offers, negotiating contracts, contract registry, and notifications about the start and end of a contract.
 - **Payment**: Includes functions for reserving funds, notifying about costs, agreeing on settlements, and making payments.
 - **Activity**: Transmitting information between parties that an activity needs to start or stop; notifications about resources consumed by the activity.

Introducing the state machine governing how services are performed by Providers, i.e. Activities.

---

arch-snapshot/arch.md line 87 at r1 (raw file):

 - **Activity**: Transmitting information between parties that an activity needs to start or stop; notifications about resources consumed by the activity.

### Business logic

I don't like this name but I am struggling to find one which is significantly better. I think "Application Logic" is slightly better, but still far from perfect. Maybe you can come up with something better?

Code quote:

### Business logic

---

arch-snapshot/arch.md line 87 at r1 (raw file):

 - **Activity**: Transmitting information between parties that an activity needs to start or stop; notifications about resources consumed by the activity.

### Business logic

I think we should mention that SDKs are a part of this layer and that there's a pretty big chunk of code prepared for users.

---

arch-snapshot/arch.md line 89 at r1 (raw file):

### Business logic

This layer utilizes components from the Core Network and Execution layers to implement applications.

I think it's worth mentioning that some implementations are provided by Golem Factory, i.e. VM provider, GPU provider, etc.

Code quote:

This layer utilizes components from the Core Network and Execution layers to implement applications.

---

arch-snapshot/arch.md line 91 at r1 (raw file):

This layer utilizes components from the Core Network and Execution layers to implement applications.

In this layer, the logic includes:

These aspects of Golem Network fall into this layer:

Code quote:

In this layer, the logic includes:

---

arch-snapshot/arch.md line 93 at r1 (raw file):

In this layer, the logic includes:

- How the contract will proceed (how long it will last, under what circumstances it can be terminated, what significance the attributes of the negotiated contract have).

How about we rephrase it a bit, so that it is easier to consume?

• Determining what to sell/buy
• Negotiating Agreements terms:
  • what to buy/sell
  • for how much
  • on what terms (how long it will last, under what circumstances it can be terminated, what significance the attributes of the negotiated contract have)
  • to/from whom
• Determining reputation of other Golem participants
• Verification of whether the Activities performed by the other party are valid
• Determining whether the costs charged by Providers is valid

---

arch-snapshot/arch.md line 106 at r1 (raw file):
I'm sorry but I don't understand it.

I'm guessing you want to write that is:

This layer is implemented either in standalone applications or is integrated into applications using Golem Network. Below are examples of of both:
VM provider - it is a standalone application (describe what it does...)
GamerHash provider - (describe)
Decentralized applications - (describe)
Ray on Golem - (describe)

Code quote:

The concept of building this layer is to create lightweight libraries in scripting languages so that various concepts can be prototyped, particularly the unsolvable problem of verifying the correctness of computations and costs.

Types of applications in this area include:

 - Provider Agent: An application that sells resources on the Core Network.
 - Requestor Agent: A purchasing application.

---

arch-snapshot/arch.md line 108 at r1 (raw file):

 - Requestor Agent: A purchasing application.

### Execution

I'm not sure they are really layers. If yes, then Application would have to be built on top of Execution which would have to be built on top of Core - please reflect this order in this document and explicitly indicate how they build on top of each other.

Code quote:

### Execution

---

arch-snapshot/arch.md line 113 at r1 (raw file):

negotiation strategies and settlement mechanisms. Regardless of these elements, the way tasks are executed is often
identical. Therefore, it might be beneficial to extract a layer responsible solely for task execution, on which it will
be easy to build custom versions of the provider agent and requestor agent.

I'm not sure I'm following this reasoning. Are you saying that had there been no execution layer, every application would have to implement one on their own?

Code quote:

When building applications in the "Business Logic" layer, it becomes apparent that the most variable elements are
negotiation strategies and settlement mechanisms. Regardless of these elements, the way tasks are executed is often
identical. Therefore, it might be beneficial to extract a layer responsible solely for task execution, on which it will
be easy to build custom versions of the provider agent and requestor agent.

---

arch-snapshot/arch.md line 115 at r1 (raw file):

be easy to build custom versions of the provider agent and requestor agent.

This layer is responsible for:

Before you list particular aspects, can you build some intuition in the reader?

Something along the lines of this:
The Core Network only specifies a way to express abstract resources and ExeUnits. Execution Layer is what gives those resources meanings, e.g. CPU, RAM, GPU and ways to utilize them (e.g. through a VM or a WASM runtime). On top of this, this layer provides all the necessary tools to allow higher level to build on top of it (e.g. transferring an VM image to a VM Provider to run). More specifically, the following aspects fall into this layer:

Code quote:

This layer is responsible for:

---

arch-snapshot/arch.md line 119 at r1 (raw file):

- Downloading images needed to execute the task (e.g., AI models or VM images)
- Managing the cache of these images
- Transferring files using various protocols

What files and between whom?

Code quote:

- Transferring files using various protocols

---

arch-snapshot/arch.md line 120 at r1 (raw file):

- Managing the cache of these images
- Transferring files using various protocols
- Launching processes and monitoring their state

ExeUnits?

Code quote:

processes

---

arch-snapshot/arch.md line 121 at r1 (raw file):

- Transferring files using various protocols
- Launching processes and monitoring their state
- Counting resource usage without relying on operating system processes

s/Counting/Monitoring/

I do not understand what you mean by "without relying on operating system processes" - after all, everything is relying on the OS.

Code quote:

Counting resource usage without relying on operating system processes

---

arch-snapshot/arch.md line 122 at r1 (raw file):

- Launching processes and monitoring their state
- Counting resource usage without relying on operating system processes
- Assigning and executing scripts with commands sent to providers

Isn't this VM-specific?

Code quote:

- Assigning and executing scripts with commands sent to providers

---

arch-snapshot/arch.md line 133 at r1 (raw file):

- GamerHash AI runtime
- Outbound gateway
- SGX runtime

One-liner explanation of what they provide would be handy.

Code quote:

- VM
- WASI
- HTTP-AUTH
- GamerHash AI runtime
- Outbound gateway
- SGX runtime

[kamirr]

Merged directly into #123