 Show Posts
|
|
Pages: [1] 2 3 »
|
Just a quick question on blockchain interoperability that REN attests to be able to handle.
If person A wants to use a smart contract on REN such that person B is only paid when a condition is achieved, which address does he send the BTC in order for REN to convert them into a BTC-equivalent on the ETH chain, and who controls that wallet? Is it to a special BTC multi-sig wallet where only a set of darknodes must collaborate to decipher the private key?
The reality of interop with Bitcoin is that the most custody you can model for some BTC is 20 signatures in a multi-sig; it’s a fundamental restriction of the protocol. To go further than this, you need something like sMPC. RenVM is the only solution I’m aware of that takes this approach with an sMPC algorithm that is fault tolerant (Dev team did a lot of R&D into this space to make this possible). If you think about porting Bitcoin to another blockchain, the best you can do is a X-out-of-20 multisig. This isn’t decentralized. So while cosmos blockchains are interoperable with other cosmos chains (or, similarly, polkadot to other polkadot chains), they cannot easily interop with other blockchains that don’t implement their protocol. The best you can do is bridges or “pegged zones” and there’s a lot of trust there (pegged zones for BTC would cap out at 20 custodians, not even as much as EOS which is widely criticised for not being decentralised). Im just referring to the underlying way in which many chains “bridge” BTC. Users send the BTC to a multisig, and then the custodians of that multisig mint a representation of BTC into the other chain. When the user burns the representation on the other chain, the custodians of the multisig send them the BTC back. Problem is: Bitcoin only supports up to 20 parties in a multisig and even these are rarely mined. RenVM takes a different approach by letting 1000s of nodes take custody of a key (essentially creating up to an X-out-of-10000 multisig). All blockchains use private keys, and therefore all blockchains are compatible with RenVMs model without having to change. RenVM could even port polkadot chains to cosmos chains! Instead of a using a multisig, RenVM uses just one private key to hold the BTC while it’s on the other chain. That private key is secret shared amongst its nodes, allowing a high degree of decentralised control. In effect, it is a massive 192 party multisig (it’s not actually though, and you wouldn’t use it in the same places you would use a multisig, it’s just a convenient way to think about how RenVM works under the hood). more: https://docs.renproject.io/ren/renvm/introduction#interoperabilityand https://renproject.zendesk.com/hc/en-us/articles/360020553254-Privacy-and-Interoperability-Questions-March-2019 |
|
|
|
When people will be able to create own DEX on your protocol? 3 blockchains is very few. ZEC is not so popular and ETH is not using a lot nowdays.
You can start doing it right now, you need to apply, to access Testnet: https://renprotocol.typeform.com/to/kARAnfWe very much encourage dev teams to do this now via MVPs and start experimenting! With these docs: 1) RenVM Overview Documentation: https://docs.renproject.io/ren2) RenVM Developer Documentation: https://docs.renproject.io/developers3) RenVM SDK: https://www.npmjs.com/package/@renproject/ren4) Example for Devs: https://github.com/renproject/uniswapZEC - may not be as popular, but this is your subjective opinion. It is important to understand that efficiency is not measured by the number of connected blockchains. Why do? Because if you have built your own Dapps based on RenVM - you can connect any blockchain to your DApps yourself. At the same time, you can configure the exchange of liquidity with other Dapps, according to pre-established rules. To do this, you do not need to contact the development REN team. Just as you do not need to contact the developers of a third-party blockchain that you want to connect. You ask such questions (about the number of supported blockchains) because you are used to thinking about interoperability as a standard to be adopted. But other blockchains should not take REN in as standard, so REN could work with them. Going back to Zcash - it's a delightful project with very hard cryptography. To establish the interoperability between ZCash and Ethereum, preserving the built-in propertis privacy of transactions, which have zcash - is difficult, but really. *Perhaps your next question will be about the speed and performance of REN  you can safely ask, I'm happy to answer you in detail. But I will say in advance that speed is important, but the answer will be similar to the answer "about the number of supported blockchains": It does not matter how many transactions per second - it's important to have enough Tps to keep up with the speed of a compatible blockchain |
|
|
|
On REN you can build a lot of interesting things, recently discussed the possibility to build a decentralized Oracle, I'll just copy the discussion text: C:
I have been thinking about sMPC-powered, incentivized, permissionless (bft), and on-demand Oracle
m:
What information would that provide? Sounds really interesting
C:
Price feeds to start with, expand over time, ideally in a no-governance no-coordination fashion .. node runners coalesce around a feed in a decentralized fashion .. each node runner opt-in to contribute a feed with skin-in-the-game ("I attest that ETHUSD price is x at this Unix time interval and I am willing to stake $x to back that and willing to get slashed if majority of the network says otherwise).
sMPC is powerful because malicious actors commit to their feeds before discovering what everyone else's feed was. sMPC also protects consumers of feeds such that the network is unaware of what is at stake when such consumers act on those feeds
M:
This makes me think of some sort of Uniswap-style oracle. Let's say each request from the oracle costs some small fee. Each input-provider gets a share of that fee in proportion to how close their input was to the combined inputs. At a certain distance away from the combined input you get into the slashing-region instead, where the farther you are the more you get slashed (we're still talking small absolute slashing). This would incentivize each input-provider to source the best data they can.
C:
Ya this is an interesting model of how reporting/consumption would work internally.. sMPC is useful in making the reporting/consumption happen "in the dark" .. that I believe increases the robustness of the Oracle (e.g. if I collude with lots of stakers to fudge the feed I'm afraid of someone even more powerful lurking in the dark waiting for a sign of misbehavior so they slash the hell out of me and walk away with so much staked money. You as a reporter do not know what others reported nor do u know who consumed the feed)
L:
Using sMPC to build oracles is a really neat idea. The technique used is actually something RenVM already kind of does in a very specific way in order to get truly random numbers in each block.
This isn’t the way it does that, but in general, if you’re trying to oraclise a numerical value that makes sense to average, you can ask all Darknodes to propose their value in secret, take 2/3rds of the answers, reveal them and order them, take the middle 50% and average the result. This has a 1/3rd safety and liveliness threshold. It’s a pretty neat idea because it protects against the classic problem of not revealing data if you know it’s not favourable. It’s also non-punishing for Darknodes that might get the answer slightly wrong because the API/data-source it uses has been attacked. |
|
|
|
Do you have exchange launched on your protocol?
At the moment, there are two demonstrations of the capabilities of REN as a Protocol: 1. Darkpool (in mainnet whithout RenVM) - https://ren.exchange/exchange2. DemoDEX (in Testnet whith RenVM) - https://renproject.github.io/renvm-demo/The team has no goals to build its own exchanges/DEX. Team develops a Protocol and shows the capabilities of the Protocol to third-party developers on demo applications. Can this exchanges support different blockchains (cross chain)?
for the present: BTC, ZEC, ETH (ERC20). A distinctive feature of connecting new blockchains is an easier way to connect. We don't need BTC to accept REN as standard, we can just connect BTC (just like any other blockchain). What dapps do you have on your protocol so far? Where I can see list of this daaps?
The team is implementing a Protocol deployment plan, which involves more than 12 third-party projects. Projects that will adopt REN - will be announced closer to the mainnet. If you look at the name of the repositories that are part of the developer documentation, you can indirectly judge which projects will adopt REN (primarily defi projects) https://github.com/renproject/uniswaphttps://github.com/renproject/kybernetwork*Again, most of the answers are here: https://renproject.zendesk.com/hc/en-us/categories/360000817693-Community-Resources**I'm not part of the team, but I'm a Ren Ambassador, so you can trust me. |
|
|
|
Is there will be own DEX for cross-chain trading? Or just protocol? And why only for ERC tokens? They are not popular anymore. You should have more options
1. REN - it's not DEX, it's protocol for DAPPS/DEX/Darkpools. 2. REN (protocol) - сan support with any chains , not only ERC 20. BTC/ZEC/ETH - chains that are already supported You might want to read this: 1. https://defiprime.com/ren2. https://medium.com/renproject |
|
|
|
|
Токен продолжает искать свою справедливую цену.
У команды есть план развертывания и адопшена, в этом плане участвуют около 12 проектов.
В ближайшее время появится большее количество демонстраций использования.
|
|
|
|
Опубликован июньский FAQ https://renproject.zendesk.com/hc/en-us/sections/360003741393-Monthly-Community-FAQ-Из самого интересного: 1. Да, похоже что, мы действительно увидим обмен BTC и ZEC к ETH, на Uniswap и Kyber первыми,без лишних оберток. 2. Описаны отличия RenVM от атомарных свапов. Недостатки, которые есть у атомарных обменов и которых нет у RenVM 3. Есть вопросы и ответы по поводу первого децентрализованного даркпула RenEx, который в данное время является демонстрацией технологии, но не коммерческим продуктом, вопросы по его обновлению и притоку ликвидности, на сколько я понял, интеграция с DEX'aми принесут ликвидность на RenEx. 4. Очередные технические вопросы про sMPC, SGX. Русское сообщество в телеграмм @renrussia |
|
|
|
ТС. А ты внутри проекта или просто фанат?
Думаю что он и то и другое не замечать таких проблем которые есть у команды в данном проекте нельзя. Вполне может быть повтор кваркчейна когда тоже хайп но в итоге слился на дно. Лучше пересидеть в других проектах которые имеют огромный потенциал роста вроде лайта или бнб. Мне действительно интересно, если вы знаете какие-то недостатки - технические или организационные, расскажите о них? Или под проблемами вы имеете в виду: 1. У них маленькая команда, около 12 человек, в основном это разработчики, которые усердно трудятся и крайне редко появляются на блокчейн-тусовках. Это проблема? 2. Может быть, проблемой вы считаете то, что они не вкладываются в маркетинг? Наверное им надо было еще в первые полгода растранжирить все 30 млн на маркетологов, так вы считаете? 3. Команда не спекулирует ценой своего токена и делает анонсы, только после того как технически вещи уже работают - это для вас тоже может быть проблемой? Про кваркчейн - вы это вообще к чему? У REN точно нет никакого хайпа, смысл проектов абсолютно разный. С таким же успехом вместо "кваркчейна", можно было подставить любой другой проект, который потерпел не удачу, но вы же сами понимаете, что это абсурдно? Из новостей проекта:В одном из двух публичных репозиториев на гит-хабе, появились примеры адаптеров для KyberSwap и Uniswap, если любой из проектов в 2019 году реализует обмен активов из одного блокчейна в другой, без необходимости заворачивать и разворачивать изначальный актив - это будет главным технологическим успехом для всей индустрии. RenVM уже это делает с BTC/ZEC/ETH (ERC-20). Если REN принесет ликвидность BTC/ZEC на, например, Uniswap и другие DeFi проекты - это будет очень большой толчек для всей индустрии. Стоит отметить, что ликвидность/обмен ZEC реализуется без потери основных технологических преимуществ ZEC - приватности. |
|
|
|
REN выпустил июньский отчёт (en): https://medium.com/renproject/june-development-update-89a73f313832- завершили проверку алгоритма консенсуса, реализованного Hyperdrive;
- реализовали и протестировали алгоритм протокола конфиденциального вычисления (secure mpc);
- документация по RenVM SDK была предоставлена некоторым сторонним проектам. Сам SDK проходит разработку, тестирование и проверку;
- выпущена документация по RenVM: https://docs.renproject.io/ren/;
- улучшена синхронизация даркнод, создана новая библиотека передачи сообщений;
- начато проектирование нового командного центра, где будут указано географическое распределение сети, технические характеристики оборудования, установленные версии и выплаты;
|
|
|
|
ТС. А ты внутри проекта или просто фанат? Я не член команды, скорее "просто фанат", участник сообщества Думаю что он и то и другое не замечать таких проблем которые есть у команды в данном проекте нельзя.
Вполне может быть повтор кваркчейна когда тоже хайп но в итоге слился на дно.
А какие проблемы есть у команды? |
|
|
|
|
На неделе команда REN была в Сан-Франциско, на саммите Polychain. В это время произошло два события:
1. Цена токена очень хорошо выросла.
Команда сделала объявление о поездке в SF уже после того, как вернулись. Как верно заметили в официальном телеграмм канале, присутствие на саммите с достаточно узким кругом участников, означало, что Loong и команда имели возможность плотно пообщаться с командами MakerDAO, dXdY и возможно Coinbase, а так же с другими проектами, в кого инвестировал фонд Polychain. Скорее всего рост цены и саммит просто совпадение, но хочется думать, что многое происходит за кулисами (о большой работе, которая не выносится на публику, неоднократно говорили сами участники команды REN)
2. В чате амбасадоров сделали объявление о переходе на 4 недельные циклы.
Что это такое. Цикл выплат - это время в течении которого вы видите заработанные награды, но они не доступны для вывода. Так же вы видите время, которое осталось до конца цикла, в конце цикла награды автоматически переходят в состояние доступное для вывода (на эту операцию тратится GAS с баланса узла). Если узел дерегистрируется до окончания цикла - он теряет награды. Если узел регистрируется в текущем цикле - он не зарабатывает награды до окончания текущего цикла, после окончания цикла, узел добавляется в белый список и только после этого начинает зарабатывать. Таким образом, когда начнется 4 недельный цикл, идеально если вы зарегистрируете узел за несколько дней до окончания цикла, чтобы не ждать несколько недель.
а еще в проекте много всего крутого происходит, лень тут писать. все новости можно узнать в группе РУ сообщества REN в телеграмме.
|
|
|
|
|
На данный момент в сети 92 даркноды.
Ожидания команды, что люди запустят 100-150 узлов.
Минимальное количество узлов для работы сети 24.
Максимально возможное, теоретическое, количество узлов 10000.
|
|
|
|
О какой баунти ветке ты говоришь? У проекта нет айрдропов или баунти. Рашен телеграм гроуп https://t.me/renrussia |
|
|
|
А какой кошелек лучше юзать для ICON?
ICONex плагин в хроме?
Или лучше пока пускай на бирже лежит?
Какой-бы ни была биржа, на ней лучше не хранить в долгосрок. Официальный кошелек ICONex, так же существует поддержка Ledger Nano S |
|
|
|
|
