Лучшая практика защиты конфиденциальной информации о надежности?

#ethereum #solidity #smartcontracts

Вопрос:

У меня есть поле в моем контракте. Это что-то вроде этого:

 contract MyContract {
    string private secretField
}

function getSecretField() public view returns {
  ... some controls here...
  return secretField;

}
 

Я хочу получить доступ к этому секретному полю с моего внутреннего сервера и защитить его от любого другого запрашивающего. Какова наилучшая практика для этого?

Ответ №1:

Если он находится в общедоступном блокчейне (mainnet, тестовая сеть ropsten, …), он всегда будет доступен, если запросить слот для хранения secretField , содержащий значение, из автономного приложения. Независимо private от модификатора видимости солидности, поскольку запрос на хранение выполняется на более низком уровне.

Пример: Если secretField является первым свойством первого определенного контракта (по этому адресу), его значение хранится в слоте хранения 0.


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

 // removed `view` because it's going to interact with the transaction data
function getSecretField() public returns {
    // reverts if the sender address is not 0x123
    require(msg.sender == address(0x123);

    return secretField;
}
 

Обратите внимание, что вашему серверному приложению потребуется send транзакция с 0x123 адреса, чтобы получить доступ к данным. Simple call ничего не вернет, потому getSecretField() view что это больше не функция.

Комментарии:

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

2. @MiratCanBayrak, Возможно, ваш вариант использования позволит хэшировать — (публично) хранить только хэш некоторого секрета и проверять его на соответствие хэшу (имейте в виду, что транзакции также являются общедоступными, поэтому вы также можете захотеть, чтобы ваши пользователи передавали хэш, а не значение перед хэшированием, например пароль). Но, вообще говоря, публичные блокчейны не являются хорошим способом хранения личных данных.