Как исходный код защищен от подделки в блокчейне?

1 
class Block{
    constructor(timestamp, transactions, previousHash = ''){
        this.timestamp = timestamp;
        this.transactions = transactions;
        this.previousHash = previousHash;
        this.hash = this.calculateHash();
        this.nonce = 0;
    }

    calculateHash(){
        return SHA256(this.previousHash + JSON.stringify(this.transactions) 
        + this.timestamp + this.nonce).toString();
    }

    mineBlock(difficulty){
        while(this.hash.substring(0, difficulty) !== Array(difficulty + 
        1).join("0")){
            this.nonce++;
            this.hash = this.calculateHash();
        }

        console.log("Block mined: " + this.hash);
    }
}

В приведенном выше коде, как это обещано, что основная логика не манипулируется одним преимуществом? Я имею в виду, чтобы добыть блок, шахтер должен инвестировать огромные вычислительные мощности. Если, скорее, он/она может сломать цикл while выше в методе mineBlock(), возможно, не так много вычислений необходимо, чтобы разбить блок и принять его (при условии, что исходный код можно было бы манипулировать во всех валидаторах/шахтерах (доказательство работы и доли соответственно) машин). Заранее спасибо.

  • 0
    Вы не можете защитить клиентский код.
  • 0
    Я не думаю, что «декомпилированный» правильно описывает ситуацию, о которой вы беспокоитесь. Это только означает, что кто-то может увидеть код контракта. Это не может быть предотвращено. Может быть, вы имеете в виду "подделка"? Это означает, что кто-то будет запускать код, отличный от того, что вы написали в контракте. Я обновлю название, но, пожалуйста, уточните, если я что-то упустил.
Показать ещё 1 комментарий
Теги:
blockchain
ethereum
solidity

2 ответа

0

возможно, не так много вычислений необходимо для того, чтобы разбить блок и принять его (при условии, что исходный код можно манипулировать на всех машинах валидатора/шахтера (доказательство работы и ставки соответственно))

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

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

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

  2. Однако в случае, если это произошло, код консенсуса может быть исправлен, и сеть восстановится, отбросив все недопустимые блоки, которые были приняты после нарушения.

Если вы предлагаете изменить код на всех шахтерах:

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

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

Поделиться
  • 0
    Спасибо за ответ на мой вопрос. Имеет смысл. Исключением может быть то, что сеть только начала расти и использует общую кодовую базу, а злоумышленник пробился в исходный код сети и успешно обошел предикат, который проверяет сгенерированный хэш и опустошает цепочку до распространения новостей. , Boom! Реакция необратима, поскольку блоки были ликвидированы. Но да Это исключение наверняка.
0

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

Такие технологии, как Bitcoin, не могут быть разрушены до тех пор, пока 51% вычислительной мощности (в случае PoW consesus) поступают от честных узлов.

В тот момент, когда более 51% вычислительной мощности повреждено (вредоносное), регистр не является безопасным.

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

Написание DLT заключается не только в написании кода без ошибок (который нельзя использовать для коррумпирования всех узлов, как вы заявляли в вопросе), но и эффективных механизмов консенсуса, которые нельзя использовать.

PoW означает "Доказательство работы". DLT означает технологию Distribuited Ledger (которая включает Blockchain, Tangles и т.д.)

Просто чтобы прояснить некоторые заблуждения, которые я видел здесь.

Solidity - это детерминированный язык, используемый для написания интеллектуальных контрактов внутри блок-цепи (это не язык, используемый для кодирования самой блок-цепи, а код, используемый для программного обеспечения, запущенного внутри блок-цепи, например: Ethereum)

Взятие Ethereum в качестве примера есть различные реализации этого, geth (golang-ethereum) является наиболее активным. Как я уже сказал, если вы хотите создать свою собственную блок-цепочку, вероятно, вам стоит попробовать повторно использовать код, который уже доказал свою надежность.

Отвечая на вопрос: "новые блокирующие группы подвержены 51% -ным атакам" (это главным образом связано с целями, связанными с достижением консенсуса): да, это абсолютно верно, новорожденные цепочки (или блокированные с низким уровнем хэша) часто подвергаются нападениям с помощью аренды hashpower (см. биткойн Частный случай произошел недавно или биткойн золото). К сожалению, нет способа предотвратить это, потому что это просто то, как работает Договор о работе, единственное, что можно сделать, чтобы сдержать это, - это то, что вы ожидаете большего количества подтверждений блоков, прежде чем рассматривать активы, исходящие от транзакции, чтобы ее можно было потратить.

Пример (имена выбраны случайным образом): у меня есть интернет-магазин, принимающий BTW (монета), исходящий из биткойн-слабого блокчлена, который часто страдает от 51% атак, что я делаю, так как хотя транзакция клиентов была вставлена в номер блока (X), я жду до номера блока (X + 100), прежде чем позволить ему потратить эти деньги на моей платформе.

Почему я это делаю? Это связано с тем, что 51% атак нацелены на воссоздание двух цепей и вставку более длинной цепочки, которая позже удаляет более короткую цепочку (ту, где я создал транзакцию, используемую для покупки на вашей платформе), поэтому более длинные блоки подтверждения ждут больше денег, которые я заставляю хакер потратить, чтобы сохранить атаку хешета на 51%. Если его двойная атака состоит в том, чтобы потратить 100 долларов, но я заставляю его тратить 101 $ на электричество (или на аренду хеш-футов), то я препятствую ему атаковать цепь и пытаться удвоить расходы на своей платформе.

Надеюсь, это прояснило ваши сомнения.

Поделиться
  • 0
    Ага. Не могу согласиться больше на 51% де-факто. Но 51% может выглядеть вполне достижимо, если цепочка находится в самом начале и имеет всего несколько блоков, верно? Однако Proof of Stake (или DLT) преодолевает эту уязвимость - в некоторой степени является передышкой. Возвращаясь к моей проблеме, я настороженно отношусь к фальсификации исходного кода, которая может быть общей точкой входа для злоумышленника и, возможно, удастся удовлетворить все узлы валидатора, хотя с меньшей вероятностью, но препятствует высокой летальности (поскольку исходный источник очень очень вероятно, что это будет распространено, если, скажем, язык, такой как Solidity, используется всеми узлами)!
  • 0
    @AbhayNagaraj Я обновил пост, разъяснив некоторые ваши сомнения и объяснив 51%, что они делают и как их отговорить.
Показать ещё 1 комментарий

Ещё вопросы

Сообщество Overcoder
Наверх
Меню