Тонкие клиенты и сети Эфириума

light-clients-ethereum-network-1024x512-08-26-2016

Последняя версия Parity привела к возобновлению дискуссии о влиянии различных типов клиентов на общее состоянии сети Эфириума.

Parity — это следующее поколение браузера Эфириума, разработанного командой Ethcore под руководством доктора Гэвина Вуда. Многие из членов команды являются самыми первыми участниками, которые создали и запустили сеть Эфириума. Их цель — разработка быстрой и надежной программы-клиента для взаимодействия с сетью Эфириума: программы, которая может быть интегрирована в браузер напрямую. Ключевыми требованиями к ней будут производительность, надежность, совместимость и простота использования.

В последней версии parity предусмотрена «функция снапшота», которая позволяет значительно ускорить синхронизацию сети. Проблема в том, что это окажет негативное влияние на состояние сети Эфириума. Если интенсивность использования клиента parity будет стремительно расти, то синхронизация с сетью значительно затруднится; так как parity не предоставляет все требуемые данные для синхронизации узлов полного клиента. Станет сложно найти надежные узлы с данными, которые им (полным клиентам) необходимы.

Посредством «функции снапшота» через Parity у нас получается так называемый толстый клиент, который использует для работы протокол Эфириума. При этом оказывается, что клиент не способен предоставить все данные, которые рассчитывает получить другой узел полного клиента сети.

Так как parity будет запущена на протоколе Эфириума, другие узлы будут ждать свою очередь, чтобы получить доступ к необходимой информации, такой как заголовки, блоки, транзакции и поступления средств. Однако клиенты parity не будут обладать этой информацией, так как она будет удалятся. С этой проблемой связано общее негативное воздействие тонких клиентов на сеть. Слишком большое их количество может сказаться на состоянии и стабильности работы сети.

Тонкими клиентами можно назвать «паразитирующими» на сети, поскольку они принимают данные от других пользователей, но сами взамен данные не отдают. В то время как в техническом плане они могут быть ‘паразитами’, в то же время фактически они в какой-то мере поддерживают сеть. По мере роста популярности сети, ее пользовательская база будет расширяться, а блокчейн — увеличиваться. Новые, технически менее грамотные пользователи будут избегать иметь дело с настройкой и поддержанием работы полного узла. Таким образом, тонкие клиенты будут способствовать расширению сети за счет простоты использования.

В некотором роде эти рассуждения построены на содержании предыдущих дискуссий касательно сети Биткойн. Однако Эфириум имеет специфический подход, который не столь широко известен. В частности, тонкие клиенты используют собственный облегченный сетевой протокол ‘LES‘ и не влияют напрямую на протокол Эфириума. Это резко отличает Эфириум от Биткойна.

Разделение сетевых протоколов на LES и Eth — это подход, который до сих пор себя оправдывает. «Функция снапшота» является таким же важным инструментом, применяемым клиентом, как и parity. Несмотря на некоторые недостатки, все вышеназванное играет важную роль.

Здесь существует тонкая грань. Хотя технически тонкие клиенты и «паразитируют» в сети, они важны для долгосрочной жизнеспособности, востребованности и полезности такой системы, как Эфириум. Так как пользовательская база будет расширятся, будет увеличиваться и количество людей, которые не захотят и не смогут использовать толстые клиенты (или полные узлы).

Будут востребованы полные узлы, которые не будут запрашивать все накопленные данные с момента создания Эфириума. Забегая вперед, вероятнее всего, различий между Eth и LES протоколами будет недостаточно. Клиенты и взаимодействия между ними будут определять состояние здоровья сети. Дальнейший путь их развития напрямую повлияет на долгосрочную жизнеспособность сети Эфириума.

Источник: ethnews Автор: Тристан Уинтерс



Рубрики:Анализ, Теория, ETH, Ethereum

Метки: , , ,

1 reply

  1. Теоретически, в эфире весь блокчейн и не нужен. Потому-что эфир это больше БД состояния, а блокчейн и история транзакций нужны чтобы доказать, что состояние у всех узлов одинаковое. Потому хранить блокчейн с начала времен может быть не обязательно, а достаточно ограничиваться последними N-блоками, наример историей транзакций за последний год. Наоборот, такой подход будет даже полезен, потому-что загрузка архивных блоков и восстановление по ним состояния с нуля, может занять много времени и просто это хранение ненужных данных. Сравните 7 Гб против > 20 Гб сейчас. Кроме того. это потенциально позволяет увеличить газлимит.

    От функции логов тогда придется отказаться, или поддерживать её самостоятельно для своего приложения. Но изнутри контрактов разницы нет.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s