한국 엘프 오픈카카오 그룹: http://bit.ly/aelfkoreakakao

한국 엘프 텔레그램 그룹: http://bit.ly/aelfkoreatele

안녕하세요, 엘프(aelf)의 한국 오퍼레이션을 담당하고있는 이준범입니다. 4월12일(목) 저희 엘프가 빗썸 거래소에 상장하게 되었습니다! 이에 더욱 많은 분들이 엘프에 관심을 가져주고 계시는데요. 저희는 이번 포스팅을 통해 엘프의 기술을 조금 더 친근하게 한번 설명해보려고 합니다. 많은 분들에게 새로운 프로젝트이기도 할 뿐더러 엘프 백서의 기술적 복잡함을 인지하고 있기에 되도록 쉽게 이해하실 수 있게 풀어봤습니다.

엘프(aelf)는 후발주자인 만큼 어려움도 있지만, 그에 따른 장점이 더 많습니다. 엘프는 다른 블록체인 3.0 프로젝트들이 개발되는 것을 지켜보면서, 블록체인 3.0이 완벽히 상용화 되고 현재 사용 되는 다른 기술과 자연스럽게 호환 되기 위해서 무엇에 집중해야 하는지를 고민했습니다. 그 결과 블록체인 2.0의 한 부분을 집중적으로 개선하기 보다는, 전체적인 시스템이 같이 개선 되야 한다고 결론을 내렸습니다. 엘프는 플랫폼 제공자입니다. 따라서 개발자와 유저에게 어떤 퀄리티를 제공해야 하는지에 대해서 가장 많이 고민했습니다. 그 결론으로 디앱(Dapp) 개발자와 유저들에게 개발 용이성, 호환성 그리고 앱의 속도 뿐만 아니라 속도의 안정성을 보장하는 플랫폼을 공급하는 것을 궁극적인 목표로 설정했습니다.

엘프의 장점이 쉽게 이해되도록 지금부터 도로와 자동차에 비유해 설명하겠습니다. 엘프를 고속도로와 자동차 엔진 제공자라고 생각하고, 스마트계약과 디앱을 자동차의 엔진을 제외한 나머지 부분이라고 생각하십시오. 여기에서 자동차를 운전하는 운전자는 대중적인 유저입니다. 준비 되셨나요? 그럼 엘프의 장점은 크게 3가지로 나누어 설명 드리겠습니다.

1.컴퓨팅 파워와 프로세싱 스피드, 즉 앞서 말한 자동차 엔진이라고 생각하시면 됩니다.

• 엘프는 DPoS 프로토콜을 베이스로 합니다. 가장 큰 차이점이 각각의 노드가 하나의 컴퓨터가 아닌 ‘컴퓨터의 집합’, 즉 ‘클라우드(Cloud)’입니다. 예를 들어 설명하자면 똑똑한 사람 혼자서 수학문제를 푸는게 아니라 똑똑한 사람 여럿이 ‘병렬’로 모여서 수학 문제를 푸는 것입니다. 이런 질문을 할 수 있습니다. 똑똑한 사람 10명이 있는 방에 수학 문제를 하나씩 던져 준다고 해서 혼자 푸는 것 보다 10배 빠른 속도로 푸는 것은 아니라는 겁니다. 어떻게 하면 각 사람의 능력을 최대로 활용할 수 있을까요? 해결 방법은 ‘병렬 처리 알고리즘 ’에 있습니다. 복잡한 문제를 여러 파트로 나눠서 10명의 사람에게 나누어 준 후 한꺼번에 문제를 풀어내는 병렬 처리 알고리즘 입니다. 다수의 자동차가 최고 속도로 달릴 수 있도록 강력한 엔진(클라우드 노드와 병력처리 알고리즘)을 개발자들에게 제공하는 논리입니다.

2. 체인의 구조, 즉 ‘도로가 어떻게 나누어져’ 있고 ‘얼마나 자동차에 최적화되어 있느냐’ 입니다

• 현존하는 대부분의 플랫폼은 메인체인에서 여러 갈래길로 나누어 지는 형태를 취하고 있습니다. 예를 들면 고속도로를 다 같이 타고가다가 막히는 구간이 나오면 새로운 도로를 추가해서 교통체증을 분산 시키는 것과 같습니다. 하지만 엘프는 처음부터 수많은 도로가 병렬식으로 나누어져 설계되어 있으며, 각각의 길은 사용하는 주요 차량의 종류에 맞게 최적화 되어 있습니다. 어떤 길은 버스에, 어떤 길은 오토바이에 또 어떤 길은 승용차에 최적화 되어 있습니다. 때문에 한 체인, 즉 한 도로가 많은 트래픽 때문에 속도가 늦어지거나 막힌다고 해도, 다른 도로는 전혀 영향을 받지 않는 구조입니다. 이 아키텍쳐는 물론 땅의 제한이 없는 가상의 통로이기 때문에 가능한 설계 입니다. 더불어 이 체인들 위를 달리는 자동차의 운전자인 코인 보유자들은 투표를 통해 도로의 넓이 또는 제한 속도와 같은 여러 질적 문제를 결정할 수 있는 권리를 가집니다. 마지막으로 엘프의 메인체인에는 어떤 스마트계약도 지나가지 않습니다. 메인체인은 모든 길의 트래픽을 관찰∙관리하고, 수많은 길이 서로 원활하게 커뮤니케이션 할 수 있도록 하는 역할을 합니다. 하늘에서 교통상황을 지켜보고 있는 헬리콥터에 비유해도 좋을 것 같습니다.

3.상호 호환성 그리고 자체진화성, 즉 도로들이 ‘서로 얼마나 연결 되어 있고’, 각 도로의 진로와 발전 방향을 결정하는 일에 유저들이 ‘어떻게 그리고 얼마나 참가할 수 있느냐’ 입니다.

• 엘프에서 스마트 컨트렉트에 참가하는 코인 보유자들은 투표를 통해 여러 결정권을 가지게 됩니다. 이 다양한 결정권들이 포괄적으로 엘프 생태계의 전체 진화 방향을 결정하게 됩니다. 코인 보유자라면 누구나 각각의 결정에 참여할 수 있습니다. 투표 가능한 안건에는 어떤 것이 있을까요? 한 사이드 체인의 고유 노드 소유 여부, 사이드 체인이 공용체인이 될지 개인체인이 될지의 선택, 사이드 체인의 크기와 속도, 새로운 체인 생성여부 등등을 예로 들 수 있습니다. 즉 엘프 플랫폼의 미래 모습은 엘프 개발자들이 아니라 유저들에 의해 정해지며, 이를 통해 진화하는 개별적인 사회가 되는 것입니다 (하드포크의 필요성도 적어지겠죠?). 엘프는 DPoS 방식을 취하지만, 이런 엘프를 최대한 많은 유저들과 다른 블럭체인이 공유 할 수 있도록 , PoW나 PoS를 취하는 다른 프로토콜(예를 들어 비트코인이나 이더리움)들과 호환이 가능케할 아답터(adapter)를 제공할 것입니다.

엘프는 현재 한국에 2개 거래소에 상장이 되어 있으며 (GoPax, Bithumb) 총 18개 거래소에 상장이 되어 있습니다 (Bitfinex, Binance, OKEX, Huobi, CEX, BCEX, Bibox, gate.io, KKEX, BigONE, OTCBTC, HYPEX, Bancor, KuCoin, RADAR, CoinTiger).

엘프는 현재 테스트넷(test-net) 단계에 있습니다. 6월 말에 전체적인 윤곽이 잡힐 것이며 이때 여러 테스팅을 시작할 것입니다. 올해 말에 메인넷(main-net)을 출시할 예정이며 코인 트랜스퍼(transfer) 또한 이때 엘프 지갑과 함께 진행할 계획입니다.

저희는 지속적으로 한국에서 엘프의 입지를 높혀 갈 계획이며 한국에 상주하고있는 저를 통해 여러 이벤트와 커뮤니티와의 소통을 이어갈 것입니다. 독자 여러분들께는 투자 전 엘프의 차별화 요소 대해 자세히 알아보시고 이해 하신 후 투자 하시는것을 강력히 추천하는 바입니다. 엘프의 장점은 기술력과 그 기술력을 현실화하는 개발팀에 있기에 어려운 면이 있지만 계속 꾸준히 공개될 새로운 컨텐츠와 인포그래픽을 통해 엘프의 목표와 솔루션을 이해해 주시길 바라는 바입니다.

블럭체인 3.0의 자리매김과 블럭체인의 상용화에 대표 주자를 목표로 하는 엘프, 지켜봐 주시면 정말 감사 드리겠습니다!

A Multi-Chain Parallel Computing Blockchain Framework

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

1. 요약

aelf는 분산된 자율 진화 클라우드 컴퓨팅 네트워크입니다. 다양한 상용화 요구사항에 따른 블록체인 인프라를 구축하기 위해서 aelf는 크로스체인 커뮤니케이션 및 자율 진화 거버넌스를 갖춘 고효율의 멀티체인 병렬 처리 시스템을 제공합니다. aelf는 최첨단 IT 설계 이론과 기술을 통합하여 블럭체인 네트워크의 완전한 상용화를 가능케 할 것입니다. aelf는 블록 체인을 위한 ‘리눅스 환경’을 창조하길 추구하며 현재 블럭체인 시스템의 가장 기본적이고 필수이며 시간이 많이 걸리는 요소를 개선하는 목적으로 마켓의 기존 블록체인들을 기반하여 많은 질적 향상을 이루었습니다. 이 시스템은 개발자들의 니즈, 특히 크고 다양한 산업에 대한 상업적 요구 사항을 만족시키기 위해 시스템을 커스터마이징 할 수 있도록 설계되었습니다.

aelf 는 보다 복잡한 스마트 컨트랙트의 신속하고 유동성 있는 이행을 목표로 하며, 각 체인에는 일체의 스마트 컨트랙트에 대한 혼잡 또는 정체가 없는 실행을 위한 자체 고유의 리소스를 제공합니다. aelf는 스마트 컨트랙트를 쉽게 업그레이드하고 자연스럽게 진화할 수 있도록 다이나믹 블록체인 시스템에 적합한 인프라를 제공 할 것입니다.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

2. 주요 기능

Independence & Specialization(자율화와 전문화)

• 개별적인 사이드체인, 그들을 연결하는 메인체인, 즉 멀티체인 시스템을 이용하여 한 스마트 컨트렉트의 네트워크 포화가 다른 스마트 컨트렉트의 처리를 방해할수 없도록 한 체인의 병렬화
• 고효율의 크로스체인 상호작용 시스템으로 순조로운 체인간의 스마트 컨트렉트 시동과 커뮤니케이션
• 퍼블릭과 프라이빗 체인 둘다 생성과 융합 가능
• 하나의 사이드체인이 한 종류의 컨트랙트를 (예: 보험산업의 멤버정보 수집및 관리) 수행하기에 맞춰져 있어 보다 쉽고 가벼운 정보 처리의 편의성이 있으며 상용 체인에 최적화 되어있음

Scailability & Processing power (확장성과 컴퓨팅 파워)

• 각각의 노드가 하나의 컴퓨터가 아닌 컴퓨터의 집합 (클라우드)으로써 컴퓨팅 파워의 극대화
• 클라우드의 다양한 컴퓨터를 최상의 효율로 활용하기위해 병렬 처리 알고리듬을 사용, 하나의 스마트 컨트랙트의 다양한 태스크를 클라우드안의 모든 컴퓨터에서 동시 다발적으로 병렬 처리
• 노드 컴퓨터의 개조 / 업그레이드가 불필요, 클라우드에 컴퓨터를 추가시킴으로서 빠르고 간단한 컴퓨팅 파워의 증가

Flexibility & Ease of development (유연성과 개발의 편의성)

• 리눅스와 같이 블럭체인 개발을 가볍고 커스터마이징이 가능하도록 함
• 사이드체인 템플렛을 제공하여 보다 쉽고 빠르게 블럭체인 개발 가능

Interoperability (상호 운영성)

• 머클트리를 활용한 크로스체인 인덱싱을 통해 컨센서스 프로토콜이 다른 블록체인과도 상호작용, 통합이 가능함 (예: 비트코인, 이더리움)

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

3. 거버넌스 구조

DPoS(Delegated proof of stake) 합의 프로토콜을 사용하여 Multi chain이라는 시스템 상에서 의사결정을 delegated node들이 합의를 이끌어 낸다.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

4. 아키텍쳐와 커널

Ælf 아키텍쳐

• Ælf의 아키텍쳐는 DPOS 컨센서스 메커니즘이 있는 하나의 메인체인과 사용자 정의, 즉 커스터마이징이 가능한 컨센서스 메커니즘이 있는 여러 개의 사이드체인이 메인체인에 인덱싱되어 작동하는 두가지 레벨을 가지고 있다. branched eco-system이라고 칭하며 메인체인이 시스템의 백본(커널)형태로 존재하며 여러 개의 사이드 체인이 동적 인덱싱을 통해 연결 되어있다.
• Ælf는 비트코인이나 이더리움 등의 다른 블록체인 시스템과 아답터를 통해 연결된다. Ælf의 사이드체인은 dApp같은 스마트컨트랙의 이행이 가능하며 또는 크로스체인 커뮤니케이션, 컨센서스 합의 등에 사용된다.
• 하나의 사이드체인이 한 종류의 컨트랙트를 (예: 보험산업의 멤버정보 수집및 관리) 수행하기에 맞춰져 있기 때문에 데이터가 간단하고 관리하기 쉬워지면서 상업적 요구사항에 맞춤화 할 수 있다.
• 사이드 체인 인덱싱 시스템을 통해 다른 블록체인이나 내부 사이드 체인들을 메인 체인에 연결할 수 있다.
• 메인체인은 사이드체인의 머클트리로부터 정보를 불러온다. 검증의 효율성을 위해 머클트리는 UTXO method의 트렌젝션 인덱싱과 account의 상태 인덱싱을 함께 수행한다.
• Ælf 토큰은 사이드 체인의 인덱싱 적용 시 그리고 사이드 체인의 거래수수료를 Ælf토큰으로 공유하게 된다.
• DPoS : Ælf는 2N+1 개의 delegated node를 위임하며 N은 8부터 시작하여 매년 1씩 증가한다. delegated node는 메인체인의 트렌젝션, 블록패키징 등의 컨센서스연산에 참여하며 일부는 사이드체인의 합의 알고리즘 연산에도 참여하게 된다.

Ælf 커널

• Ælf 커널은 Ælf블록체인의 side체인의 Ælf 커널을 통해 커스터마이징이 가능하도록 스마트컨트랙트, 컨센서스 프로토콜, 블록체인 헤더에 대한 내용을 포함하고 있다.
• Ælf 은 블록 내 병렬 트렌젝션을 통하여 high TPS 블록체인 시스템 개발을 목표로 한다.
• Ælf 의 스마트컨트렉트는 마이크로 서비스(작은 단위의 단일 수행 모듈)로 정의가 되는데 이는 프로그래밍 언어에 독립적으로 될 수 있다.
• 클라우드 베이스 : 마이크로 서비스의 방식을 통하여 AElf커널은 클라우드기반의 병렬처리를 통한 스마트컨트랙트 실행이 가능하게 된다.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

5. 기회

• 기존의 플렛폼(이더리움)이 가지고 있는 한계점(스케일링, 합의알고리즘, 인터체인 기능 등)을 보완한 새로운 블록체인 플렛폼을 지향하여 플렛폼시장 에서의 우위를 차지하는데 목표를 가지고 있음
• 특히, Ælf는 블록체인의 commercial 서비스제공에 중점을 둔다. 디지털 비즈니스 서비스를 지원하기 위해 금융서비스, 보험, 신원조회, 국가 정부조직 유틸리티, 사물인터넷 등의 서비스에 대한 토대를 마련했으며 이러한 서비스 제공에 목표를 두고 있다고 말한다.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

6. 주의할점

• 3세대 블록체인; next ethereum을 지향하는 프로젝트는 이미 무수히 많이 있다, 이중에서도 터무니 없이 3세대만을 주장하는 플렛폼도 많이 있지만 역시 가공할 만한 잠재성을 보이는 블록체인 프로젝트와 서포트를 위한 파운데이션도 다양하다. 3세대 블록체인을 지향하고 파이를 차지하기 위해서는 기술 뿐만 아니라 인플루언서를 가질 수 있도록 해야 할 것이다. 또한 플렛폼의 성사는 dApp에 달려있다고 볼 수도 있기에 이에 대한 dApp 환경조성에도 힘을 써야 할 것이다.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Link

- Homepage : https://aelf.io/

- Facebook : https://www.facebook.com/AELFkorea/

- Telegram : https://t.me/aelfkorean

- Github : https://github.com/aelfProject

- aelf candy : https://candy.aelf.io

aelf는 독립적인 트랜잭션을 위해 병렬 처리를 사용합니다.

1. aelf는 정적 트랜잭션 상태를 분석하고 각 트랜잭션의 영향을 받은 데이터 범위를 평가합니다. 아래 그림에서 볼 수 있듯이 읽기/쓰기 충돌이 없는 트랜잭션 들은 각 트랜잭션의 출력에 영향을 미치지 않는 여러 그룹으로 분류 할 수 있습니다

2. 블록이 형성되는 과정 중에, 노드는 트랜잭션의 뮤텍스(mutex)를 기반으로 다른 그룹에 트랜잭션을 할당합니다. 그룹 내 트랜잭션은 순차적으로 처리되며 모든 그룹의 트랜잭션은 동시에 처리됩니다.

3. 다른 트랜잭션이 처리되는 동안 데이터 범위가 변경되는 영향을 받는 특수 트랜잭션의 경우, 노드는 병렬로 처리 할 수 있는 트랜잭션의 우선 순위를 결정합니다. 충분한 거래 수수료가 있으면 비 병렬 그룹의 특수 트랜잭션이 순서대로 처리됩니다.

병렬 처리는 Amdahl의 법칙에 의해 명료하게 설명 될 수 있습니다.

(f : 향상되는 시스템의 비율(%), m : 성능향상 index)

Amdahl의 법칙에 따르면 전체 작업의 성능(속도)은 시스템 리소스의 개선과 함께 증가하지만 이론적인 성능(속도) 향상이 시스템 개선에 관계없이 제한되는 구간이 존재합니다.

대부분의 계좌(account)간 트랜잭션은 뮤텍스(mutex) 이므로 병렬처리가 가능합니다. 그러나 기존의 블록체인 기술은 데이터를 순서대로 처리하므로 많은 컴퓨팅 리소스가 낭비됩니다. EVM(이더리움 가상머신)을 예로 들면, 모든 데이터 및 수요 가스 요금에 대해 순차적 처리를 사용하기에 처리 효율이 낮습니다.

aelf는 컴퓨팅 파워가 증가함에 따라 스케일링(확장성)이 가능하게 합니다.

데이터 처리 속도 자체만을 최적화하는 것이 궁극적인 목표는 아닙니다. 병렬 처리의 중요성은 확장성에 대한 잠재력에 있습니다.

우리는 모두 이더리움의 확장성이 이슈가 되어 화두에 올랐던 것을 알고 있습니다. 문제는 이더리움의 오직 한 노드가 트랜잭션을 순차적으로 처리 할 수 ​​있다는 사실에 있습니다. 따라서 이더리움의 전체 처리 속도는 가장 느린 노드에 의해 제한됩니다.

코스모스는 간단한 솔루션을 제공합니다 : “한 영역에서 너무 많은 사람들이 사용하여 트랜잭션 속도가 느려지는 경우 허브에 다른 영역을 추가하고 해당 영역을 통해 사용자의 절반이 이용하도록 지시하여 트랜잭션 속도가 두 배가됩니다”

그러나 더 많은 컴퓨팅 파워가 추가되었음에도 영역당 트랜잭션 처리의 효율성은 여전히 ​​제한적입니다.

aelf는 트랜잭션을 처리하는데 있어 클라우드 컴퓨팅을 도입했습니다. aelf의 자체 커널은 각 노드가 컴퓨터 클러스터에서 작동 할 수 있게 합니다. 이것은 더 많은 컴퓨팅 파워가 aelf 에코 시스템에 합류하면 시스템 보안성을 향상 시킬 뿐만 아니라 트랜잭션 속도를 컴퓨팅 파워에 비례하여 증가 시킨다는 것을 의미합니다. 그림에서 볼 수 있듯이, aelf 그룹의 읽기 / 쓰기 충돌 없이 일어난 트랜잭션을 서로 다른 카테고리로 분류하고, 서로 다른 트랜잭션 그룹을 동시에 처리합니다.

그러나 스케일링은 다양한 주제입니다. 인센티브 메커니즘 및 합의 메커니즘을 통해 확장성(scaling)을 가장 효과적으로 달성 할 수 는 방법에 대해 생각해 볼 가치가 있습니다. aelf의 토큰 디자인과 컨센서스는 이 분야에서 흥미로운 연구가 될 것 같습니다. 그리고 그것이 이 시리즈의 다음 주제가 될 것 입니다.

자세한 내용은 공식 웹 사이트를 방문하거나 텔레그램에서의 실시간 토론에 참여하세요!

공식 웹사이트 : http://aelf.io/
텔래그램 : https://t.me/aelfkorean
또는,
Facebook: https://www.facebook.com/AELFkorea/

--------------------------------------------------------------------------------------------------------

v

One of the biggest obstacles for Blockchains serving the real business world is its low transaction speed. This situation has been seen in centralised computing systems in the past where certain transactions may take minutes or hours to solve with powerful microprocessors. This limits the possibility of what computing services can serve. Fortunately, computer scientists have been using an efficient approach to improve computing performance: parallel processing.

aelf: Parallel processing to handle commercial-scale transactions and possibilities for scaling

One of the biggest obstacles for Blockchains serving the real business world is its low transaction speed. This situation has been seen in centralised computing systems in the past where certain transactions may take minutes or hours to solve with powerful microprocessors. This limits the possibility of what computing services can serve. Fortunately, computer scientists have been using an efficient approach to improve computing performance: parallel processing.

aelf uses parallel processing for independent transactions

1. aelf analyzes the static state of transactions and assesses the impacted data range of each transaction. As illustrated in the Figure, transactions without read/ write conflicts can then be categorised in different groups, each not affecting the output of each transaction.

2. During the process of Block formation, nodes assign transactions to different groups based on mutex of the transactions. Transactions within a group will adopt sequential processing, while all groups will be processed simultaneously.

3. For special transactions whose impacted data range changes while other transactions are being processed, nodes will prioritize transactions that can be processed in parallel. With sufficient transaction fees, these special transactions in a non-parallel group will be processed in sequence. Otherwise nodes can reject to process these transactions.

Parallel processing can be fairly explained by Amdahl’s law.

The law shows that the execution of the whole task increases with the improvement of the resources in the system and that regardless of the magnitude of the improvement, the theoretical speedup is always limited by the part of the task that cannot benefit from the improvement.

Most of the transactions between accounts are mutex, thus can be processed in parallel. However, existing Blockchain technologies process data in sequence, leaving a large amount of computing resources wasted. Take EVM as one example, it adopts sequential processing for all the data and demand gas fees, resulting in low processing efficiency.

aelf enables scalable performance as computational power increases

Optimizing data processing speed itself is not the ultimate goal. The significance of parallel processing is the potential for scalability.

We have all seen the heated debate on the scalability of Ethereum. The difficulty lies in the fact that one node on Ethereum can only process transactions in sequence. Thus the whole processing speed of Ethereum is limited by the slowest node.

Cosmos provides a straightforward solution — — “if your transaction speed slows in one zone because too many people are using it, you simply add another zone to the hub and direct half the users over that zone, thereby doubling your transaction speed”. However, the efficiency of processing transactions per unit is still limited even when more computing power was added.

aelf introduces cloud computing in processing transactions. The aelf Kernel enables each node to operate on a cluster of computers. This means when more computational power joins the aelf eco-system, it not only enhances system security but also grows transaction speed proportionally. As illustrated in the figure, aelf groups transactions without read/write conflict into different categories, and then process different groups of transactions simultaneously.

Scaling, however, is a multidimensional subject. It is worth thinking about how scaling can be best achieved through an incentive mechanism and consensus mechanism. aelf’s token design and consensus is likely to provide an interesting exploration in the field. And this will be the next topic for this series articles.

While stabilizing the core we are also planning the next steps. The Kernel is going to be run in a computing cluster (numerous computers together in the same network). As said earlier one of the roles of the Scheduler is to send transactions to be executed by worker machines. In order for this to work we need to design and implement the network layer and the communication protocol for in-cluster communication.