Как спроектировать масштабируемую сеть блокчейна Эфириума?

К сожалению, Ethereum не очень масштабируем. Если вы хотите что-то изменить в файле Genesis. вам придется перенастроить все узлы. По крайней мере, на данный момент это не позволяет вам динамически масштабироваться.

1. Если это просто новый пользователь, вам нужна новая учетная запись, которая может быть на любом из двух узлов. Добавление еще одного узла не будет проблемой, просто этот файл генезиса не может измениться или вы перенастроите все. Кроме того, чтобы быть в одной и той же частной цепочке блоков, ваши файлы генезиса должны быть одинаковыми, а идентификатор сети должен быть одинаковым.

2. Поймите разницу между учетной записью, узлом и сервером. На сервере может размещаться несколько узлов, ваши узлы — это то, что вы используете для подключения к сети, и учетная запись может быть на любом из ваших узлов, вы можете перемещать его по сети. (Возьмите с собой хранилище ключей). Итак, когда вы говорите купить, вы делаете транзакции, вы можете только отправить. Что-то вроде DApp и смарт-контракта позволит выполнить логику, которую вы запрашиваете, и кто-то отправит вам эфир со своей «учетной записи» на вашу «учетную запись». Ваши балансы и история транзакций остаются в блокчейне.

3. Пиры — это в основном узлы, когда вы выполняете admin.addPeer, вы подтверждаете их существование в сети. Quorum, который является форком Ethereum, позволяет очень динамично добавлять пиров. А также обеспечивает высокий TPS.

1- Теперь этот частный блокчейн готов, и если мне нужно добавить нового пользователя, означает ли это, что мне нужно запустить новый сервер, и на этом сервере я должен выполнить описанные выше шаги?

Нет. Вы путаете проблемы платформы с проблемами приложений.

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

Слово "пользователь" перегружено. Это может быть отдельный человек или организация, комитет, устройство. В конечном счете, смысл этого заключается в проблеме приложения, которое имеет дело с такими вопросами, как полномочия и контроль доступа. Это выражается в контрактном дизайне.

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

Контрактам безразлично, какие узлы пользователи используют для отправки транзакций.

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

2- Как эти кошельки (кошельки ETH) настраивают свою инфраструктуру? Есть ли у них один сервер, подключенный к общедоступной цепочке блоков Эфириума? и любой новый пользователь, который присоединяется/покупает эфир из этих кошельков, в основном добавляется в эти кошельки как учетная запись, а не как новый пир?

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

Частный блокчейн (обычно) использует то же программное обеспечение узла. Создатель проектирует топологию, отвечающую требованиям к репликам, безопасному доступу (каждый «пользователь» должен подключаться как минимум к одному узлу), связности между узлами, возможно, за VPN, обычно по крайней мере с одним узлом в каждом участвующем узле. организации, чтобы они могли независимо интерпретировать блокчейн, не полагаясь на конкурентов, где стимулы могут не совпадать.

3. Из приведенных выше двух вопросов я понял, что в основном существует так много бирж или кошельков, которые подключены к общедоступной цепочке блоков как одноранговые, и люди, которые покупают или продают с помощью этих кошельков, в основном являются учетными записями этих кошельков. (добавлен новый аккаунт, например: personal.newAccount("xux"))

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

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

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

Когда новый узел присоединяется к сети, первое, что он делает, — загружает блоки, которые содержат хорошо упорядоченную историю транзакций, и сам запускает транзакции, как журнал воспроизведения. Когда узел полностью пойман, он будет в согласии с остальной частью сети.

(Полные) Узлы аналогичны репликам базы данных в том смысле, что они содержат полную историю состояний всех пользователей и всех контрактов. Узлы во всем согласны. Это может помочь думать о контрактах как о хранимых процедурах. Произвольное обновление не допускается. Например, системному администратору не разрешено INSERT INTO TABLE .... Все ограничены, send(data, {to: contract})и контракт решит, допустимо ли обновление.

Мошеннический узел просто потерял бы консенсус с остальной частью сети. Сеть просто проигнорирует мошеннический узел, потому что другие узлы, самостоятельно оценив историю транзакций, придут к выводу, что они не согласны с мошенническим, и поэтому должны его игнорировать.

Консенсус в частной цепочке имеет другие ограничения, чем консенсус в публичной цепочке. Следовательно, существуют варианты Ethereum, такие как Quorom. В любом случае шаблоны проектирования для распределенных систем сильно отличаются от систем, ориентированных на серверы, но пропускная способность транзакций и вопросы конфиденциальности могут рассматриваться иначе, чем в случае с общедоступной основной сетью.

Надеюсь, поможет.

Я не думаю, что вам нужно добавлять сервер для каждого пользователя, а четко определить свои требования.

Хотели бы вы иметь блокчейн Консорциума, в котором есть несколько предопределенных разрешенных узлов?

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